the Fremantle Porting Task Force,
or "how to run maemo on Neo900"

the thread title says it all.

This thread is dedicated to discussion about concepts and details of how to port maemo fremantle OS to Neo900 (Neo900 - finally a successor of N900) - or more generally to new hw platforms - , incl new volunteers introducing themselves in here, and occasional references to the Neo900 hw design and implications which the fremantle porting might have to the hw design.

Next post will summarize the foundation concepts and other relevant details.

Everybody who wants to contribute in porting (and during that step by step "freeing") fremantle, please don't hesitate to post in here. Or ask about Fremantle Porting Task Force and Neo900 in IRC(freenode.net):#maemo
Please take any posts clearly related to Neo900-the-device (when to buy, what's the hw-features, etc pp) to the Neo900 thread linked above. Thanks! This thread is for developers only.

cheers
jOERG

the mantra:
first we try to fix the fremantle core system foss bits to match the new hw platform.
if that can't be done we try to patch the kernel device drivers so the new device looks like the the N900 one to userland
if that can't be done we try to RE userland blobs or binary-patch them or write bridging-adapters from one ABI to the other
if that can't be done we need to adapt the hw platform to more closely resemble the N900.

Better alternative to the "closed packages" link above: http://wiki.maemo.org/Porting/Closed_Packages
Also see http://wiki.maemo.org/Porting !

Our "foundation": http://omappedia.org/wiki/Maemo_Getting_Started#Beagle

Highly relevant:
http://elinux.org/N900
http://wiki.maemo.org/Porting

Some definitions of landmarks:
DM3730 is considered thumb-safe
charging in Neo900 will be similar to reference implementation (TWL4030-based), so no bme blob needed [edit: this is not finally decided on yet, we might use more N900-alike charging (edit2) or even use something completely new that doesn't need any cpu support at all but isn't based on twl4030 either which is what we do now] , but we need some replacement that offers same data to HAL.
Audio hardware will be 99% compatible to n900 hw, to accommodate fremantle audio blobs like alsaped and nokia proprietary PA plugins. Except for modem audio which will be a plain I2S PCM stream (just like the codec has one), instead of some obscure "network-attached" stream tunneled through ISI aka phonet0 hw interface (the notorious cntspeech).

nice info:
http://processors.wiki.ti.com/index....igration_Guide (for unclear reasons I get a "not allowed to acccess..." with Konqueror. FF works)

About camera (about meego/sailfish, but for stuff like zerocopy and omap3camd and how stuff works it applies to fremantle as well, more or less):
http://talk.maemo.org/showthread.php...55#post1397155


Some concerns about this porting project err about Neo900 err about CSSU and how it might get negatively influenced by FPTF: http://talk.maemo.org/showthread.php?t=91399

only what i can say is thank you,everybody

i realy want to buy,but not now.can i buy one after a year?

Here are my thoughts on what to do with the N900 closed packages for the Neo900 (as listed in http://wiki.maemo.org/Fremantle_closed_packages)

Packages where usable open replacements/clones exist (or where the actual N900 source code has been found and is now available) and that we can modify to our needs
bme-rx-51
browser-neteal
osso-graphics-game-chess
osso-sounds-game-chess
osso-sounds-game-mahjong
osso-graphics-game-mahjong
mp-fremantle-generic-pr
libcal-dev
libcal1
initrd-progs
tablet-browser-view-test
calendar-home-applet
libbmeipc0
libtrace-dev
libtrace0
tone-generator
pulseaudio-policy-enforcement
ohm-plugin-prolog
ohm-plugin-resolver
ohm-plugins-misc
libprolog0
prolog-extensions
dsp-manager
gstreamer0.10-dsp
libdres0
libexempi-dev
libexempi3
docpurge
hald-addon-bme
camera-firmware
libmaemosec-certman-applet0
maemosec-certman-applet
status-area-applet-battery
status-menu-applet-profiles
libprofile-dev
libprofile-doc
libprofile0
maemo-applet-profiles
profiled
profile-data
profile-data-dev
bluetooth-sysinfo
libppu0
libwl1251
wl1251-cal
policy-settings-rx51 (assuming that the output of this matches with the original prolog binary file before it was decompiled we should be able to use this package as a base in our new system)
osso-systemui-tklock
osso-systemui-powerkeymenu
osso-systemui-alarm
osso-calculator
osso-calculator-ui
osso-applet-notificationlight
osso-applet-display
connui-home-cellular
maemo-applet-tvout
maemo-statusmenu-fmtx
libmaemosec-certman0
libmaemosec0
maemosec-certman-common-ca
maemosec-certman-tools
hildon-im-fkb
libhildon-im-western-plugin-common3
libhildon-im-vkbrenderer3
getbootstate
feedservice-plugin-fb-common
clock-ui
camera-ui
calendar-backend
calendar-backend-dev
calendar-backend-doc
tablet-browser-daemon

Packages I think we can drop completly as non-essential for a working system: (including things that go away because we are using different hardware to the N900)
amazon-installer
ap-installer
as-config-applet-0
as-daemon-0
as-utils
status-area-applet-activesync-0
ovi-promotion-widget
sharing-service-ovi
sharing-service-facebook
sharing-service-flickr
feedservice-plugin-fb
feedservice-plugin-amazon
feedservice-plugin-ap
facebook-installer
facebook-services
foreca-installer
foreca-weather-applet
cherry
camel-as-provider-0
camelisync
rtcom-accounts-plugin-facebook
nokiamessaging
nokia-maps-core
nokia-maps-maplets
nokiamaps-navigation-provider
nokia-maps-ui
dtg-installer
modest-nokiamessaging-plugin
cmt-firmware-rx51
bt-firmware
wl1251-firmware
nolo
libgles1
libgles1-sgx-img
libgles1-sgx-img-dev
libgles2
libgles2-sgx-img
libgles2-sgx-img-dev
opengles-sgx-img-common
opengles-sgx-img-common-dev
libas-common-ui-0
libas-common-utils-0
libas-protocol-0
libas-storage-0
liblas1
location-daemon
location-proxy
libnavigation-dev
libnavigation0
libmaesync
maesync-backend
maesync-controller
modest-as-plugin-0
osso-maesync-plugin
osso-maesync-ui
testserver
fmtx-middleware
fmtx-middleware-doc
funambol-cpp-api
flasher
sdk-fiasco-gen
softupd
rtcom-accounts-plugin-nokiachat

Packages we can probably keep using as-is without needing to make changes:
adobe-flashplayer
osso-accounts-plugin-skype
rtcom-abook-skype-plugin
rtcom-skype-emoticons-theme
skyhost-bin
skyhost-vengine
telepathy-spirit
cellmo-headers
cellmo-icpr82-headers
hildon-theme-alpha
hildon-theme-beta
hildon-theme-devel
ui-fonts
chinese-font
eff-content-fonts
calendar
calendar-ui
calendar-ui-widgets-0
calendar-ui-widgets-0-dev
applet-datetime
google-search-widget
hildon-control-panel-personalisation
clockd-settings-mr0
hildon-desktop-applet-settings-mr0
hildon-desktop-application-shortcuts-mr0
maemo-ringtones-mr0
tablet-browser-bookmarks-mr0
theme-default-settings-mr0
imageviewer
mediaplayer
mediaplayerhomeapplet
mediaplayer-restore
maemo-input-sounds
osso-sounds-rtc
osso-sounds-ui
osso-filemanager
osso-filemanager-ui
osso-graphics-game-lmarbles
connui-statusbar-bluetooth
connui-btsettings
location-control
location-status
location-ui
location-home-applet
location-settings-default
location-test-gui
locale-resolver-data
libi18n-dev
libi18n-locale-resolver0
libi18n0
libjpeg62
libjpeg62-dev
libjpeg62-dbg
connui-conndlgs
connui-conndlgs-bluetooth
osso-sketch
osso-notes
osso-icons-default
osso-icons-devel
libspeex-dev
libspeexdsp-dev
libspeexdsp1
libspeexdsp1-dbg
libspeex1
libspeex1-dbg
maemo-applet-fmtx
maemo-installer-utils
maemointernal-keyring
maemo-statusmenu-headset
maemo-statusmenu-volume
statusbar-alarm
speex-doc
ezitext-czech
ezitext-danish
ezitext-dutch
ezitext-english-gb
ezitext-english-us
ezitext-essential-plugins
ezitext-finnish
ezitext-french-ca
ezitext-french-fr
ezitext-german
ezitext-greek
ezitext-italian
ezitext-norwegian
ezitext-polish
ezitext-portuguese-pt
ezitext-russian
ezitext-spanish-es
ezitext-spanish-us
ezitext-swedish
imengines-ezitext
libezitext
libcityinfo-dev
libcityinfo-doc
libcityinfo0-0
osso-applet-languageregional
osso-applet-memory
osso-applet-textinput
nokia-apps
nokia-binaries
libimengines-wp4
libimengines4
libimlayouts0
libhildon-time-zone-chooser0-0
libcodelockui1
libcodelockui1-dev
feedservice
feedservice-utils
osso-rss-feed-reader-list
osso-applet-device
osso-applet-devicelock
osso-abook-home-applet
osso-addressbook
libosso-abook
libosso-abook-dev
libosso-abook-doc
rtcom-accounts-plugin-gtalk
rtcom-accounts-plugin-jabber
rtcom-accounts-plugin-sip
rtcom-accounts-ui
rtcom-accounts-voip-support
rtcom-notification-ui
rtcom-presence-ui
wappushd
wappushd-dev
xml2wbxml
osso-startup-wizard
modest-home-applet
modest-providers-data
mafw-iradio-source-bookmarks-default
osso-systemui
osso-systemui-devlock
osso-systemui-splashscreen
osso-systemui-conf
librtcom-accounts-ui-client-dev
librtcom-accounts-ui-client0
librtcom-accounts-ui-dev
librtcom-accounts-widgets-dev
librtcom-accounts-widgets0
libsharing-plugin-dev
libsharing-plugin-doc
libsharing0
sharing-account-manager
sharing-dialog
sharing-dialog-dev
sharing-dialog-doc
sharing-manager
sharing-rtcom
signond-dev
signond0
signond-utils
libsignon-glib-dev
libsignon-glib0
libssoautologin
liblomesa0
libnips0
libosal0
libgpx0
libdevlock-bin
libdevlock1
hildon-im-common-virtual-settings
hildon-im-keyboard-assistant
hildon-im-keyboard-assistant-scv
hildon-im-plugin-base-settings
hildon-im-virtual-keyboard-layouts
hildon-input-method-configurator
hildon-input-method-plugins-western
hildon-input-method-widgets
hildon-application-manager-settings-standard
hildon-plugins-notify-sv
hildon-startup-progress
hildon-welcome-default-logo
libaccounts-dev
libaccounts-doc
libaccounts-glade
libaccounts0
libconbtui0
libclockcore-dev
libclockcore0-0
libtime-dev
libtime-doc
libtime0
gst-nokia-wm
gstreamer0.10-hantro
gstreamer0.10-wma
libcumulus0
libtopos0
immvibe
libimmvibe0
libimmvibe0-dev
libcail-common
libcail-dev

Packages where we need to decide what to do:
tutorial-home-applet (need to figure out whether to write new tutorial, keep existing tutorial or drop altogether)
hildon-status-bar-usb (probably need to clone this and make changes to account for plans for USB improvements in Neo900)
osso-backup (do we drop this completly, write a new backup app that does its own thing, write a backup app that is functionally compatible/output compatible with the N900 app or keep using the existing N900 app as-is)
mce (are we able to use the Fremantle MCE as-is, do we base something off the released Meego/Harmattan MCE source, do we reverse engineer the Fremantle MCE or do we write something totally new to do this job)
clockd (may need to clone and modify this if the way clock works changes e.g. cellular network provided clock)
clockd-doc (may need to clone and modify this if the way clock works changes e.g. cellular network provided clock)
gstreamer0.10-nokia-speech (not sure whether we need this or not and if we do, what to do about it)
alsa-policy-enforcement (not sure if audio stack will change and what to do with this)
libiphb-dev (not sure if we still need iphb going forward and if so whether we need to clone it or whether we can use it as-is)
libiphb0 (not sure if we still need iphb going forward and if so whether we need to clone it or whether we can use it as-is)
iphbd (not sure if we still need iphb going forward and if so whether we need to clone it or whether we can use it as-is)
policy-application-detector (dont know what to do with this)
libplayback-1-dev (not sure if libplayback will need to change due to changes in audio stuff or whether we can keep using it as-is)
libplayback-1-doc (not sure if libplayback will need to change due to changes in audio stuff or whether we can keep using it as-is)
libplayback-1-0 (not sure if libplayback will need to change due to changes in audio stuff or whether we can keep using it as-is)
osso-systemui-actingdead (not sure if this is still needed going forward or not)
osso-systemui-modechange (not sure if this is still needed going forward or not)

For the cellular modem we need to decide whether to A.Reverse engineer the cellular services daemon and its plugins and modify ofono or fsogsmd to export the same interfaces, B.Reverse engineer the things that talk to the cellular modem and replace them with new bits that do the same thing but talk to existing ofono/fsogsmd interfaces C.Some combination of A and B or D.Go lower level and parse the ISI data that's sent to the modem and convert them into whatever we need in order to talk to the modem in the Neo900.
For some bits (e.g. status bar widgets or the ICD GPRS plugin) it may be easier to rewrite. For others (e.g. dialer) rewriting is not an option and we need to make the new low level bits do what those upper level bits need:

Cellular modem low-level bits:
csd-base
csd-call
csd-gprs
csd-info
csd-sat
csd-sms
csd-ss
libcscall2
libcsnet-dev
libcsnet0
libisi-glib0
libisi1
libsimpb0
libsim0
libsms-utils0
libsms0
libss1
libtelcommon0
phonet-at
phonet-utils
ssc-daemon
sms-manager
libphinfo0

Cellular UI bits that talk to the low level bits:
connui-cellular-settings
rtcom-call-ui
rtcom-messaging-ui
connui-conndlgs-cellular
connui-statusbar-cellular
telepathy-ring
evolution-data-server-addressbook-backend-sim
gprs-provisioning
libconnui-cellular
librtcom-call-ui0
osso-mission-control
operator-wizard-settings
ota-settings
osso-systemui-emergency

For the internet connectivity daemon and wlan bits and such we need to figure out whether to keep using the binary blobs below or to replace them (and which ones to replace):
connui-conndlgs-internet
connui-conndlgs-wlan
connui-iapsettings
connui-iapsettings-gprs
connui-iapsettings-wlan
connui-statusbar-internet
osso-wlan-security
icd2
icd2-dev
icd2-network-wlan-config
icd2-settings-default
libicd-network-dummy
libicd-network-eap
libicd-network-gprs
libicd-network-ipv4
libicd-network-wlan
libicd-network-wlan-dev
libicd-network-wps
libicd2
libconnui

For GPS, the way to go is to replace the below packages with drop-in replacements that talk to the GPS chip in the Neo900
liblocation-dev
liblocation0
liblocation0-doc

For pulseaudio packages below, since our hardware is different, we probably dont need to use these, if we do, what do we do about them? Use whatever the various alternate OSs on the N900 are doing? (i.e. whatever the MeeGo-on-N900 work has morphed into these days) Reverse engineer these? Replace them completly?
pulseaudio-module-nokia-common
pulseaudio-module-nokia-music
pulseaudio-module-nokia-record
pulseaudio-module-nokia-voice
pasr

For browser UI and bits, do we A.Keep existing closed UI as-is B.Clone some or all of closed UI and modify it C.Write totally new UI that replaces existing UI but keeps same open backend (browserd etc) or D.Use totally different browser for N900 and ditch microb completly? Browser bits are as below:
osso-bookmark-engine
osso-bookmark-engine-dev
osso-browser
tablet-bookmark-manager
tablet-browser-controls
tablet-browser-default-plugin
tablet-browser-dialogs
tablet-browser-mediaplayer-plugin
tablet-browser-ui
tablet-browser-view
tablet-browser-view-dev
tablet-browser-widgets

For camera, not sure if we need to keep using the below packages, clone them and change for whatever new hardware we have or write something new:
libomap3cam
omap3camd
libhllc0

For the sysinfo libraries we probably need to create drop-in replacements that do the same job but fit our stack:
libsysinfo0
osso-product-info
libossoproductinfo0
sysinfo-common
sysinfod
sysinfo-tool

For the DSP stuff, we may need new bits for whatever chip we have, we may need to replace these things, we may need to drop them completly, I dont know.
libipp-nokia
gstreamer0.10-ipp-nokia
omap3430-dsp-baseimage-ti
omap3430-dsp-libraries-ti
libbridge2
libomxil-ti-components
libomxil-ti0

awesome work! incredibly valuable. I boggled from it. Should this go onto a wiki page so we can edit/comment as needed?

Dropping SGX usermode bits doesn't look like something we can do IMO. Otherwise there will be no GLES, which means no games and no HW accelerated gecko (for example).

I think we should swallow those blobs

On a side note - my understanding is that our ultimate goal is to have one (or 2, but very close) distribution to be used on both N900 and Neo900. I won't agree on dropping N900 support in favor of Neo900. Just saying

My point about the SGX blobs is that whatever chip ends up in the Neo900 will have a GPU that is different enough that the existing N900 blobs wont work (at least that's an assumption) and therefore we will use different blobs that go with the GPU in the Neo900.

Well, plans so far (afaik) are Neo900 to have SGX535/540, so we still have to use those blobs, albeit newer version

I think it would be better to stick to one distribution, so long as it doesn't impede performance of either device. I'm thinking if one device can get better performance using a specific compiler option for a specific package or have a feature disabled on N900 due to lack of memory.

Hardware specific packages should be pretty straight forward, using metapackages. Been trying to work out how to word my suggestion but got in a mess with package this and package that. Decided it was easier to illustrate.

N900-Adaptation

• provides: hw-adaptation
• depends: N900 specifics, using >= version

Neo900-Adaptation

• provides: hw-adaptation
• depends: Neo900 specifics, using >= version

Obviously, this may need some modification to existing packages on N900.

microb (and related) wise, maybe see where Alopex is heading. I think we would need to do something even if it is just to increase security and compatibility.

Finally, I would like to see the Facebook rtcom plugin stay.

It seems like reimplementing CSD daemon is the way to go (so I'd go for option C). ISI has lots of undocumented parts, and it should be easier to RE dbus APIs than ISI ones.

Neo900 will have the same Option module as GTA04 does. I think we can use work done by FSO (http://freesmartphone.org/) and take fsogsmd as a middleware that's going to talk directly with the modem, as it already has good GTA04 suppor. API docs: http://docs.freesmartphone.org/
(we might consider oFono as well, but I would strongly recommend fsogsmd)

We will have to reimplement CSD dbus API. For that some reverse engineering will be needed, as there is very small amount of documentation for those:
http://wiki.maemo.org/N900_dbus

DBus API documentation will also come handy for working with different parts of the OS, so I suppose collecting it has pretty high priority.

Some insightful discussion happened today on #maemo-cssu regarding replacing closed blobs, especially GSM daemon. The most interesting part starts at 15:02: http://mg.pov.lt/maemo-ssu-irclog/%2...09-07.log.html