Maemo Reconstructed - Revision history

imported_>amigadave: use ambox

2011-03-04T14:10:07Z

use ambox

← Older revision		Revision as of 14:10, 4 March 2011
Line 1:		Line 1:
	~~<div style~~=~~"border: 1px #0a0 solid; background-color: #efe; padding: 10px; padding-left: 20%; padding-right: 20%; text-align: center; margin: 10px;">~~		{{ambox\|text=[[Maemo Reconstructed]] was a proposal that eventually led to the '''Mer''' project. You can find out more about Mer on its Wiki page: [[Mer]], where you can also download flashable images and get involved in the project.}}
	~~'''~~Maemo Reconstructed~~'''~~ was a proposal that eventually led to the '''Mer''' project. You can find out more about Mer on its Wiki page: [[Mer]], where you can also download flashable images and get involved in the project.
	~~</div>~~

	Our goal is to bring together Nokia and community developers who have an interest in the Maemo platform and reach a vision of the future Maemo system architecture that's satisfying to both Nokia and the community.		Our goal is to bring together Nokia and community developers who have an interest in the Maemo platform and reach a vision of the future Maemo system architecture that's satisfying to both Nokia and the community.

imported_>amigadave: Category:Mer

2010-03-03T15:21:44Z

Category:Mer

← Older revision		Revision as of 15:21, 3 March 2010
Line 221:		Line 221:

	Again, Maemo SDK+ seems to provide much of this and is definately the way to go regarding SDK plugins (GUIs, Anjuta as an example). Through a simple interface it could be extended to provide deploying and remote debugging features. GDB supports remote debugging for instance.		Again, Maemo SDK+ seems to provide much of this and is definately the way to go regarding SDK plugins (GUIs, Anjuta as an example). Through a simple interface it could be extended to provide deploying and remote debugging features. GDB supports remote debugging for instance.

			[[Category:Mer]]

imported_>dneary: /* The Maemo "Reconstructed" platform */

2010-02-01T21:33:35Z

The Maemo "Reconstructed" platform

← Older revision		Revision as of 21:33, 1 February 2010
Line 30:		Line 30:
	There should exist scripts and documented methods for creating a Maemo "R" image that can be adapted to any setup or device. It should be easy to build your own jffs2 image.		There should exist scripts and documented methods for creating a Maemo "R" image that can be adapted to any setup or device. It should be easy to build your own jffs2 image.

	Development of the Maemo "R" platform (non-device-specific and non-vendor-specfic differentiation) should be done in the open, with public SCM, bugtrackers and blueprints. This way, developers can adjust their applications to later 'stable' releases and know what is coming regarding the Maemo API.		Development of the Maemo "R" platform (non-device-specific and non-vendor-specfic differentiation) should be done in the open, with public SCM, bugtrackers and [[Mer/Blueprints \| blueprints]]. This way, developers can adjust their applications to later 'stable' releases and know what is coming regarding the Maemo API.

	One of the goals of the Maemo "R" platform is that it should be easy to port an existing desktop application by hildonizing it and adjusting to the form factor of a tablet, without having to deal with platform particularities like what features the busybox version of a tool uses or other factors. A secondary goal is to have a platform that is flexible enough to encourage experimentation and development for tablets.		One of the goals of the Maemo "R" platform is that it should be easy to port an existing desktop application by hildonizing it and adjusting to the form factor of a tablet, without having to deal with platform particularities like what features the busybox version of a tool uses or other factors. A secondary goal is to have a platform that is flexible enough to encourage experimentation and development for tablets.

imported_>thp: Add link to the Mer project, which is the result of this proposal

2009-12-30T14:48:35Z

Add link to the Mer project, which is the result of this proposal

← Older revision		Revision as of 14:48, 30 December 2009
Line 1:		Line 1:
			<div style="border: 1px #0a0 solid; background-color: #efe; padding: 10px; padding-left: 20%; padding-right: 20%; text-align: center; margin: 10px;">
			'''Maemo Reconstructed''' was a proposal that eventually led to the '''Mer''' project. You can find out more about Mer on its Wiki page: [[Mer]], where you can also download flashable images and get involved in the project.
			</div>

	Our goal is to bring together Nokia and community developers who have an interest in the Maemo platform and reach a vision of the future Maemo system architecture that's satisfying to both Nokia and the community.		Our goal is to bring together Nokia and community developers who have an interest in the Maemo platform and reach a vision of the future Maemo system architecture that's satisfying to both Nokia and the community.

imported_>tor: 2 minor typos.

2008-12-11T16:36:38Z

2 minor typos.

← Older revision		Revision as of 16:36, 11 December 2008
Line 135:		Line 135:
	** In the case of OMAP framebuffers, work has been done at http://gitweb.pingu.fi/?p=xf86-video-omapfb.git;a=tree for a Xorg driver for both BeagleBoards and N8x0, packaged for Debian at http://nchipin.kos.to/deblet/		** In the case of OMAP framebuffers, work has been done at http://gitweb.pingu.fi/?p=xf86-video-omapfb.git;a=tree for a Xorg driver for both BeagleBoards and N8x0, packaged for Debian at http://nchipin.kos.to/deblet/
	* '''GStreamer'''		* '''GStreamer'''
	** Part of Maemo platform as of now, ideal for codecs, include vendor-specific ~~propertiary~~ ones.		** Part of Maemo platform as of now, ideal for codecs, include vendor-specific proprietary ones.
	* '''PulseAudio'''		* '''PulseAudio'''
	** Part of [[Task:Maemo roadmap/Fremantle]]. Optional part of platform? What does Maemo really target of device types?		** Part of [[Task:Maemo roadmap/Fremantle]]. Optional part of platform? What does Maemo really target of device types?
Line 145:		Line 145:
	** The base graphical framework of Maemo. This GTK version should be Maemo 'GTK', but the following things should hold true for the Maemo GTK.		** The base graphical framework of Maemo. This GTK version should be Maemo 'GTK', but the following things should hold true for the Maemo GTK.
	*** Maemo GTK is designed for power-saving low-freq devices. It is designed for touchscreens and with memory conservation in mind		*** Maemo GTK is designed for power-saving low-freq devices. It is designed for touchscreens and with memory conservation in mind
	*** It should not alter ~~it's~~ behaviour in such a way that a certain window manager or desktop environment is needed to run applications using this toolkit. If this change of behaviour is needed, the toolkit should detect the WM/DE and enable the behaviour if it's Hildon+Matchbox.		*** It should not alter its behaviour in such a way that a certain window manager or desktop environment is needed to run applications using this toolkit. If this change of behaviour is needed, the toolkit should detect the WM/DE and enable the behaviour if it's Hildon+Matchbox.
	*** It should not change upstream API (but may add or cause breakage that would make normal GTK applications not work with it.		*** It should not change upstream API (but may add or cause breakage that would make normal GTK applications not work with it.
	* '''GTKMM'''		* '''GTKMM'''

imported_>stskeeps at 21:24, 9 November 2008

2008-11-09T21:24:08Z

← Older revision		Revision as of 21:24, 9 November 2008
Line 13:		Line 13:

	Thanks to Ryan Abel for proofreading and to other #maemo members for comments.		Thanks to Ryan Abel for proofreading and to other #maemo members for comments.

			A small bunch of individuals are working on a proof of concept of this platform, can be followed on http://jaiku.com/channel/reconstructedPOC and on irc.freenode.net #maemo.

	== The Maemo "Reconstructed" platform ==		== The Maemo "Reconstructed" platform ==

imported_>stskeeps at 10:06, 8 November 2008

2008-11-08T10:06:28Z

← Older revision		Revision as of 10:06, 8 November 2008
Line 200:		Line 200:
	Vendors should strive for contributing hardware emulation for QEMU for their devices or provide stubs inside the hardware support packages but should act as close to the actual device as possible.		Vendors should strive for contributing hardware emulation for QEMU for their devices or provide stubs inside the hardware support packages but should act as close to the actual device as possible.

	There should exist a reference generic Maemo "R" platform to develop for, with associated emulator - in the proof of concept this will be ~~ARMv5EL & QEMU Versatile~~-PB.		There should exist a reference generic Maemo "R" platform to develop for, with associated emulator - in the proof of concept this will be the n800 machine and arm1136-r2 CPU emulated in qemu.

	Vendors should provide emulator images (in the form of flash images, disk images) associated to the device rootstraps to make users able to test on their platforms.		Vendors should provide emulator images (in the form of flash images, disk images) associated to the device rootstraps to make users able to test on their platforms.

	N8x0 emulation is already seen (http://blog.haerwu.biz/2008/04/11/nokia-n800-emulation/). Being able to boot their development environments will allow the user to instantly test how their applications work on the actual device or an emulated version.		N8x0 emulation is already seen (http://blog.haerwu.biz/2008/04/11/nokia-n800-emulation/) and in qemu SVN HEAD. Being able to boot their development environments will allow the user to instantly test how their applications work on the actual device or an emulated version.

	Maemo SDK+ already provides the "maemo-runtime" scripts which could be adapted to include features like this.		Maemo SDK+ already provides the "maemo-runtime" scripts which could be adapted to include features like this.

imported_>stskeeps at 14:45, 7 November 2008

2008-11-07T14:45:22Z

← Older revision		Revision as of 14:45, 7 November 2008
Line 188:		Line 188:
	=== Maemo "R" rootstraps ===		=== Maemo "R" rootstraps ===

	The SDK should contain at least one rootstrap - the Maemo "R" base OS, targeted towards both cross-compilation ~~and an associated emulator CPU+emulated device. The base rootstrap could be~~ for instance ~~Maemo "R" base OS~~ targeted towards ARMv5EL and the QEMU versatile-pb emulator.		The SDK should contain at least one rootstrap - the Maemo "R" base OS, targeted towards both cross-compilation towards the reference platform, for instance targeted towards ARMv5EL and the QEMU versatile-pb emulator.

	Developers should be encouraged to develop for this ~~base~~ platform - the ~~generic~~ Maemo "R" platform. Though, there will be device-specific features that vendors would like to make developers able to develop for. The vendors would then either provide hardware support packages to include on top of the base OS or provide additional rootstraps which represent the ~~firmware~~ shipped on the actual tablets with build-essentials and such on top. These rootstraps or packages would probably be provided under some kind of licensing scheme.		Developers should be encouraged to develop for this platform API - the reference Maemo "R" platform API. Though, there will be device-specific features that vendors would like to make developers able to develop for. The vendors would then either provide hardware support packages to include on top of the base OS or provide additional rootstraps which represent the device and device-specific APIs shipped on the actual tablets with build-essentials and such on top. These rootstraps or packages would probably be provided under some kind of licensing scheme.

	~~The goal of a rootstrap is that it is, indeed, a complete OS image and can be:~~		A rootstrap may be either device-specific (processor types/etc) or have device-specific packages in it. Vendors providing device-specific interfaces for the platform should strive towards standardizing similar types of hardware interfaces (HAL battery templates come to mind, GPS or Bluetooth interfacing), but the vendor may provide subtypes of the APIs - extended APIs for component-specific things.

	* user-level emulated (qemu-arm) - run the emulated binaries inside your system (normal usage is when cross-compiling)
	* system-level (qemu-system-arm) - boot the emulated device with your rootstrap (NFS comes to mind?)
	* actual device (tablet, for instance) - boot your rootstrap with your device through usbnet/NFS, test how it works on the actual tablet.

	A rootstrap may be either device-specific or have device-specific packages in it. Vendors providing device-specific interfaces for the platform should strive towards standardizing similar types of hardware interfaces (HAL battery templates come to mind, GPS or Bluetooth interfacing), but the vendor may provide subtypes of the APIs - extended APIs for component-specific things.

	Maemo has great possibility to become a general platform for tablet like devices. The possibility of additional device platforms which also embrace the Maemo "R" base direction will cause every Maemo-using device to have additional applications as well when they appear for other devices.		Maemo has great possibility to become a general platform for tablet like devices. The possibility of additional device platforms which also embrace the Maemo "R" base direction will cause every Maemo-using device to have additional applications as well when they appear for other devices.
Line 206:		Line 200:
	Vendors should strive for contributing hardware emulation for QEMU for their devices or provide stubs inside the hardware support packages but should act as close to the actual device as possible.		Vendors should strive for contributing hardware emulation for QEMU for their devices or provide stubs inside the hardware support packages but should act as close to the actual device as possible.

	There should exist a reference generic Maemo "R" platform to develop for, with associated emulator.		There should exist a reference generic Maemo "R" platform to develop for, with associated emulator - in the proof of concept this will be ARMv5EL & QEMU Versatile-PB.

			Vendors should provide emulator images (in the form of flash images, disk images) associated to the device rootstraps to make users able to test on their platforms.

	N8x0 emulation is already seen (http://blog.haerwu.biz/2008/04/11/nokia-n800-emulation/). Being able to boot their development environments will allow the user to instantly test how their applications work on the actual device or an emulated version.		N8x0 emulation is already seen (http://blog.haerwu.biz/2008/04/11/nokia-n800-emulation/). Being able to boot their development environments will allow the user to instantly test how their applications work on the actual device or an emulated version.

imported_>sjgadsby: /* SDK (developer kit for the platform) */ removing commas from before coordinating conjunctions in compound predicates

2008-11-07T14:24:15Z

SDK (developer kit for the platform): removing commas from before coordinating conjunctions in compound predicates

imported_>sjgadsby: /* Deployment and debugging support scripts */ removing comma from before coordinating conjunction in compound predicate

2008-11-07T14:13:30Z

Deployment and debugging support scripts: removing comma from before coordinating conjunction in compound predicate

← Older revision		Revision as of 14:13, 7 November 2008
Line 218:		Line 218:
	Work could be done on easy deployment of developed packages (# sb-copy-to-tablet -i usb, -i emu, etc) or running in similar manner to sbrsh with NFS and the likes.		Work could be done on easy deployment of developed packages (# sb-copy-to-tablet -i usb, -i emu, etc) or running in similar manner to sbrsh with NFS and the likes.

	Again, Maemo SDK+ seems to provide much of this, and is definately the way to go regarding SDK plugins (GUIs, Anjuta as an example). Through a simple interface it could be extended to provide deploying and remote debugging features. GDB supports remote debugging for instance.		Again, Maemo SDK+ seems to provide much of this and is definately the way to go regarding SDK plugins (GUIs, Anjuta as an example). Through a simple interface it could be extended to provide deploying and remote debugging features. GDB supports remote debugging for instance.

← Older revision		Revision as of 14:24, 7 November 2008
Line 170:		Line 170:
	A prime example is Maemo SDK+, http://maemo-sdk.garage.maemo.org/		A prime example is Maemo SDK+, http://maemo-sdk.garage.maemo.org/

	Maemo "R" SDK should not only focus on native application development, but also embrace developer environments for non-native languages such as Python, Java, etc, to show the versatile nature of the Maemo "R" platform. Maemo SDK+ would be able to contain these, and could also allow for Eclipse-based development environments etc.		Maemo "R" SDK should not only focus on native application development, but also embrace developer environments for non-native languages such as Python, Java, etc, to show the versatile nature of the Maemo "R" platform. Maemo SDK+ would be able to contain these and could also allow for Eclipse-based development environments etc.

	Maemo "R" SDK should not be the only way to develop for the tablet - it should be just as possible to get the needed compilers and dev packages and be able to compile on tablet - which is easy as the rootstrap is really the Maemo "R" OS with build-essentials packages on top.		Maemo "R" SDK should not be the only way to develop for the tablet - it should be just as possible to get the needed compilers and dev packages and be able to compile on tablet - which is easy as the rootstrap is really the Maemo "R" OS with build-essentials packages on top.
Line 188:		Line 188:
	=== Maemo "R" rootstraps ===		=== Maemo "R" rootstraps ===

	The SDK should contain at least one rootstrap - the Maemo "R" base OS, targeted towards both cross-compilation and an associated emulator CPU+emulated device. The base rootstrap could be for instance Maemo "R" base OS targeted towards ARMv5EL, and the QEMU versatile-pb emulator.		The SDK should contain at least one rootstrap - the Maemo "R" base OS, targeted towards both cross-compilation and an associated emulator CPU+emulated device. The base rootstrap could be for instance Maemo "R" base OS targeted towards ARMv5EL and the QEMU versatile-pb emulator.

	Developers should be encouraged to develop for this base platform - the generic Maemo "R" platform. Though, there will be device-specific features that vendors would like to make developers able to develop for. The vendors would then either provide hardware support packages to include on top of the base OS or provide additional rootstraps which represent the firmware shipped on the actual tablets with build-essentials and such on top. These rootstraps or packages would probably be provided under some kind of licensing scheme.		Developers should be encouraged to develop for this base platform - the generic Maemo "R" platform. Though, there will be device-specific features that vendors would like to make developers able to develop for. The vendors would then either provide hardware support packages to include on top of the base OS or provide additional rootstraps which represent the firmware shipped on the actual tablets with build-essentials and such on top. These rootstraps or packages would probably be provided under some kind of licensing scheme.

	The goal of a rootstrap is that it is, indeed, a complete OS image, and can be:		The goal of a rootstrap is that it is, indeed, a complete OS image and can be:

	* user-level emulated (qemu-arm) - run the emulated binaries inside your system (normal usage is when cross-compiling)		* user-level emulated (qemu-arm) - run the emulated binaries inside your system (normal usage is when cross-compiling)
Line 198:		Line 198:
	* actual device (tablet, for instance) - boot your rootstrap with your device through usbnet/NFS, test how it works on the actual tablet.		* actual device (tablet, for instance) - boot your rootstrap with your device through usbnet/NFS, test how it works on the actual tablet.

	A rootstrap may be either device-specific or have device-specific packages in it. Vendors providing device-specific interfaces for the platform should strive towards standardizing similar types of hardware interfaces (HAL battery templates come to mind, GPS or Bluetooth interfacing), but vendor may provide subtypes of the APIs - extended APIs for component-specific things.		A rootstrap may be either device-specific or have device-specific packages in it. Vendors providing device-specific interfaces for the platform should strive towards standardizing similar types of hardware interfaces (HAL battery templates come to mind, GPS or Bluetooth interfacing), but the vendor may provide subtypes of the APIs - extended APIs for component-specific things.

	Maemo has great possibility to become a general platform for tablet like devices. The possibility of additional device platforms which also embrace the Maemo "R" base direction will cause every Maemo-using device to have additional applications as well when they appear for other devices.		Maemo has great possibility to become a general platform for tablet like devices. The possibility of additional device platforms which also embrace the Maemo "R" base direction will cause every Maemo-using device to have additional applications as well when they appear for other devices.
Line 204:		Line 204:
	=== QEMU, able to emulate target device(s) emulated ===		=== QEMU, able to emulate target device(s) emulated ===

	Vendors should strive for contributing hardware emulation for QEMU for their devices, or provide stubs inside the hardware support packages, but should act as close to the actual device as possible.		Vendors should strive for contributing hardware emulation for QEMU for their devices or provide stubs inside the hardware support packages but should act as close to the actual device as possible.

	There should exist a reference generic Maemo "R" platform to develop for, with associated emulator.		There should exist a reference generic Maemo "R" platform to develop for, with associated emulator.