https://pandorawiki.org/api.php?action=feedcontributions&feedformat=atom&user=LollaPandora Wiki - User contributions [en]2026-05-03T19:55:40ZUser contributionsMediaWiki 1.32.0-alphahttps://pandorawiki.org/index.php?title=Kernel_interface&diff=29124Kernel interface2013-11-27T10:14:15Z<p>Lolla: </p>
<hr />
<div>{{hint|For apps use higher level libraries/interfaces like SDL, Qt, X or similar for your own good (portability). It may be impossible to retain this layout on some major hardware revision, let's say Pandora 3000, and your program will break. Also this requires some level of Linux programming knowledge.}}<br />
<br />
In case you need to write low level code (you can't/don't want to use high level libs like [[SDL]]), you can use kernel interface. This is the recommended way to access hardware (as opposed to GP2X style of accessing chip registers by mmap'ing /dev/mem), because in case hardware changes are needed in future, they could be handled by kernel and all programs would still work. It also should allow several programs to work at the same time and should be more stable.<br />
<br />
==Input==<br />
Buttons, keypad, touchscreen and [[nubs]] are all exposed through Linux event interface (EVDEV). All devices are represented by '''/dev/input/eventX''' files, which can be opened, read and queried (using ioctl calls). The reads can be synchronous (the read will only return when user does something, like presses the button), or asynchronous (the system will report what changed since the last time you asked).<br />
<br />
{{warning<br />
|Don't hardcode device filenames in your program!<br />
}}<br />
<br />
For example, currently /dev/input/event2 represents game buttons, but in future it may become touchscreen. Scan input device names instead, example:<br />
<source lang="c"><br />
for (i = 0; 1; i++)<br />
{<br />
sprintf(name, "/dev/input/event%i", i);<br />
fd = open(name, O_RDONLY);<br />
if (fd < 0) break; /* no more devices */<br />
ioctl(fd, EVIOCGNAME(sizeof(name)), name);<br />
if (strcmp(name, "gpio-keys") == 0)<br />
return fd; /* found the buttons! */<br />
close(fd); /* we don't need this device */<br />
}<br />
</source><br />
<br />
List of device names and events they send:<br />
{|class="wikitable"<br />
|-<br />
!name<br />
!description<br />
!event.type<br />
!event.code<br />
!event.value<br />
|-<br />
|keypad<br />
|keypad<br />
|EV_KEY<br />
|KEY_0...KEY_Z, KEY_BACKSPACE, KEY_LEFTSHIFT, KEY_SPACE, KEY_ENTER, KEY_COMMA, KEY_DOT, KEY_FN<br />
|0 - released<br> 1 - pressed<br> 2 - autorepeat event<br />
|-<br />
|gpio-keys<br />
|game buttons<br />
|EV_KEY<br />
|KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT, KEY_MENU (Pandora button), KEY_LEFTALT (Start), KEY_LEFTCTRL (Select), KEY_PAGEUP (Y/North), KEY_HOME (A/East), KEY_PAGEDOWN (X/South), KEY_END (B/West), KEY_RIGHTSHIFT (Shoulder L), KEY_RIGHTCTRL (Shoulder R), KEY_KPPLUS (Shoulder L2), KEY_KPMINUS (Shoulder R2), KEY_COFFEE (Hold)<br />
|0 - released<br> 1 - pressed<br />
|-<br />
|gpio-keys<br />
|lid state<br />
|EV_SW<br />
|SW_LID<br />
|0 - closing<br> 1 - opening<br />
|-<br />
|touchscreen<br />
|touchscreen<br />
|EV_ABS<br />
|ABS_X, ABS_Y, ABS_PRESSURE<br />
|varies, use calibration data<br />
|-<br />
|nub0<br />
|left nub<br />
|EV_ABS<br />
|ABS_X, ABS_Y<br />
| -256 (Left/Up)<br>0<br>+256 (Right/Down)<br />
|-<br />
|nub1<br />
|right nub<br />
|EV_ABS<br />
|ABS_X, ABS_Y<br />
| -256 (Left/Up))<br>0<br>+256 (Right/Down)<br />
|}<br />
<br />
Sample code:<br><br />
[http://beagleboard.googlecode.com/files/evtest.c evtest.c]<br />
[http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-misc.git;a=blob;f=op_test_inputs.c;hb=HEAD op_test_inputs.c]<br />
<br />
===Nubs===<br />
Nubs have 3 modes that can be switched during runtime: absolute, mouse, mbuttons; this can be done by writing one of those 3 strings to /proc/pandora/nubX/mode . On mode change /dev/input/event* device reenumeration starts and files belonging to nubs are recreated and must be reopened.<br />
<br />
<strong>Warning:</strong> it is not guaranteed that input files will finish recreating after a write to /proc/pandora/nubX/mode finishes, it is application's responsibility to wait until those files are available.<br />
<br />
To solve the above problem, the OS provides a helper script that will wait for enumeration to complete:<br />
<source lang="bash"><br />
/usr/pandora/scripts/op_nubchange.sh <left_num_mode> <right_nub_mode><br />
</source><br />
op_nubchange.sh is not available on HF6 or earlier firmwares, to support them, something like this could be used:<br />
<source lang="bash"><br />
if [ -e /usr/pandora/scripts/op_nubchange.sh ]; then<br />
/usr/pandora/scripts/op_nubchange.sh absolute absolute<br />
else<br />
echo absolute > /proc/pandora/nub0/mode<br />
echo absolute > /proc/pandora/nub1/mode<br />
fi<br />
</source><br />
<br />
===Touchscreen===<br />
Event interface returns uncalibrated values directly from driver, so you need to use tslib or manage calibration yourself (using data from /etc/pointercal).<br />
<br />
===X11===<br />
When using the direct kernel api for input, it is also important to stop X processing the events as well. To do this you can create an X window to eat the events. There is also a utility that comes with the Pandora to do this:<br />
<source lang="c"><br />
op_runfbapp ./yourapp<br />
</source><br />
<br />
==Sound==<br />
Pandora uses ALSA, but it has OSS emulation enabled too, so GP2X code should work.<br />
<br />
==Video==<br />
===Architecture===<br />
Framebuffer device (/dev/fbX) is supported. There are 3 framebuffers available ('''/dev/fb0''', /dev/fb1 and /dev/fb2), which represent 3 graphics/video layers on OMAP3 by default (but can be reconfigured). Only /dev/fb0 is enabled by default.<br />
<br />
OMAP3 display subsystem is controlled by a driver known as DSS2, which has various controls available on /sys/devices/platform/omapdss/ (but they are not meant to be changed by programs, so they are root writable only). The driver exposes 3 layers (called overlays) and 2 displays. Overlays 1 and 2 can perform hardware scaling on the fly using 5-tap poly-phase filter, overlay0 can not. Displays 0 and 1 represent LCD and TV respectively. By default the 3 framebuffers (/dev/fbX) are redirected to 3 overlays, which all output to the LCD. This configuration is not meant to be changed by programs, only firmware should manage these.<br />
<br />
===Basic usage===<br />
====framebuffer interface====<br />
Framebuffers can be accessed Linux fbdev interface:<br />
<source lang="c"><br />
fbdev = open("/dev/fb0", O_RDWR);<br />
buffer = mmap(0, 800*480*2, PROT_READ | PROT_WRITE, MAP_SHARED, fbdev, 0);<br />
</source><br />
(this is basic example, no error checks)<br />
<br />
the returned pointer can be used to draw on the screen.<br />
<br />
Be sure to #include <linux/fb.h> to get access to the FB device ioctl interface, and <sys/ioctl.h> for access to ioctl itself.<br />
<br />
====double buffering====<br />
This can be achieved using FBIOPAN_DISPLAY ioctl system call. For this you need to mmap framebuffer of double size<br />
<source lang="c"><br />
buffer1 = mmap(0, 800*480*2 * 2, PROT_WRITE, MAP_SHARED, fbdev, 0);<br />
buffer2 = (char *)mem + 800*480*2;<br />
</source><br />
<br />
Then to display buffer2 you would call:<br />
<source lang="c"><br />
struct fb_var_screeninfo fbvar;<br />
ioctl(fbdev, FBIOGET_VSCREENINFO, &fbvar);<br />
fbvar.yoffset = 480;<br />
ioctl(fbdev, FBIOPAN_DISPLAY, &fbvar);<br />
</source><br />
going back to buffer1 would be repeating above with fbvar.yoffset = 0. Tripple or quad buffering can be implemented using the same technique.<br />
<br />
====vertical sync====<br />
Linux has standard FBIO_WAITFORVSYNC for this:<br />
<source lang="c"><br />
int arg = 0;<br />
ioctl(fbdev, FBIO_WAITFORVSYNC, &arg);<br />
</source><br />
be sure to pass argument value 0 or it will not work.<br />
<br />
Some toolchains don't have FBIO_WAITFORVSYNC defined in <linux/fb.h>, in which case you can define it in the following manner:<br />
<br />
<source lang="c"><br />
#ifndef FBIO_WAITFORVSYNC<br />
#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)<br />
#endif<br />
</source><br />
<br />
====hardware scaling====<br />
Overlay1 (/dev/fb1) can be used to achieve hardware scaling. Technically overlay2 (fb2) can be used for this too, but it is planned to be used by the system for TV-out functionality, so don't use it. The overlay is configured using series of standard and OMAP specific ioctl calls, but the system ships with some tools to achieve this from scripts too. This way the framebuffer can be set up for some arbitrary size (say 320x240) and can output to LCD as 800x480 with hardware scaling.<br />
Here is an example script:<br />
<source lang="bash"><br />
ofbset -fb /dev/fb1 -pos 0 0 -size 800 480 -mem 307200 -en 1<br />
fbset -fb /dev/fb1 -g 320 240 320 480 16<br />
<br />
./your_app_here<br />
<br />
ofbset -fb /dev/fb1 -pos 0 0 -size 0 0 -mem 0 -en 0<br />
</source><br />
<br />
What it does:<br />
* allocates OMAP DSS layer, asks video output to be 800x480 at position 0,0 (could set it to 640x480 at 80,0 instead to get centered 2x scaling of 320x240). 307200 bytes of video memory are allocated for 2 320x240 16bpp screens (for doublebuffering).<br />
* sets video mode to 320x240@16bpp, virtual resolution 320x480 for doublebuffering.<br />
* runs your app<br />
* cleans the video layer on exit<br />
<br />
Now the program can act as if it works with 320x240 16bpp screen.<br />
<br />
====LCD refresh rate====<br />
The OS has a dedicated script which can change the LCD refresh rate. It must be ran with sudo:<br />
<source lang="c"><br />
sudo -n /usr/pandora/scripts/op_lcdrate.sh 50<br />
</source><br />
From code, system() function can be used for this.<br />
<br />
'''Note''': this doesn't mean your program has to run as root to use this (it never should!), just run the script as shown above.<br />
<br />
====gamma====<br />
Since SZ 1.52, gamma can be controlled with another script, the same way as LCD refresh:<br />
<source lang="c"><br />
sudo -n /usr/pandora/scripts/op_gamma.sh 1.0<br />
</source><br />
where 1.0 is the gamma level. If supplied gamma level is 0, then user defaults are used (useful to set on exit). There is also an optional -b N argument (to be specified before gamma value), where N controls black level (0-255, useful to combat LCD ghosting).<br />
<br />
===Hardware scaling filter control===<br />
The hardware scaler in pandora uses poly-phase 5-tap 8-phase filter. It is described in 15.4.2.3.4 and 15.6.1.3 sections of TRM. There are 40 coefficients programmable for both horizontal and vertical resampling (vertical resampling might also use 3 taps/24 coefficients, it depends on available pixel clock).<br />
====using predefined filters====<br />
Just run 'sudo /usr/pandora/scripts/op_videofir.sh <name>', where name currently can be:<br />
* default - the default filter from OMAP manual<br />
* none - nearest neighbor<br />
====using custom filters====<br />
run 'sudo /usr/pandora/scripts/op_videofir.sh <basename>', where basename* files contains coefficient table. The script will look for <basename>_h, <basename>_v3 and <basename>_v5 files for 5-tap horizontal, 3-tap vertical and 5-tap vertical configurations respectively. Pass absolute or relative path for basename with './', like './something'. The coefficients should be in a form of table like described in TRM, for example:<br />
<source lang="c"><br />
----<br />
0 0 128 0 0<br />
-1 13 124 -8 0<br />
-2 30 112 -11 -1<br />
-5 51 95 -11 -2<br />
0 -9 73 73 -9<br />
-2 -11 95 51 -5<br />
-1 -11 112 30 -2<br />
0 -8 124 13 -1<br />
</source><br />
For 3-tap table, first and last columns should contain zeros.<br />
<br />
==LEDs and Display backlight==<br />
The LEDs can be controlled via '''/sys/class/leds/''', and then a file [http://www.gp32x.com/board/index.php?s=&showtopic=45309&view=findpost&p=673593]:<br />
* pandora::sd1<br />
* pandora::sd2<br />
* pandora::charger<br />
* pandora::power<br />
* pandora::bluetooth<br />
* pandora::wifi<br />
* pandora::keypad_bl<br />
Backlight can be controlled via '''/sys/class/backlight/'''.<br />
<br />
==Battery==<br />
There is bq27500 battery monitoring chip onboard, that exports various files at /sys/class/power_supply/bq27500-0/ , for example 'capacity' tells charge percenage left. See Data_provided_by_Battery_and_Power_driver for more details.<br><br />
There are also similar directories at /sys/class/power_supply/twl4030_* that provide info while charging.<br />
<br />
==Misc==<br />
===Overclocking===<br />
Can be performed by running a helper script<br />
<source lang="bash"><br />
sudo /usr/pandora/scripts/op_cpuspeed.sh X<br />
</source><br />
In case you want to do it from another program or non-interactively, you can use system() function (or similar) with:<br />
<source lang="bash"><br />
sudo -n /usr/pandora/scripts/op_cpuspeed.sh -n X<br />
</source><br />
* Note: you are advised not to change the clock explicitly from a program because optimal clock may differ on different pandora revisions, or somebody might want to run at different clock speed to save battery, CPU life, etc. . Let the user decide about the clock before running the program and set it using the system tools.<br />
* Note: '-n' script argument is not available on pre-SuperZaxxon Final firmwares.<br />
<br />
[[Category:Development]]<br />
[[Category:Kernel]]<br />
[[Category:Hardware]]</div>Lollahttps://pandorawiki.org/index.php?title=Kernel_interface&diff=29123Kernel interface2013-11-27T10:08:40Z<p>Lolla: </p>
<hr />
<div>{{hint|For apps use higher level libraries/interfaces like SDL, Qt, X or similar for your own good (portability). It may be impossible to retain this layout on some major hardware revision, let's say Pandora 3000, and your program will break. Also this requires some level of Linux programming knowledge.}}<br />
<br />
In case you need to write low level code (you can't/don't want to use high level libs like [[SDL]]), you can use kernel interface. This is the recommended way to access hardware (as opposed to GP2X style of accessing chip registers by mmap'ing /dev/mem), because in case hardware changes are needed in future, they could be handled by kernel and all programs would still work. It also should allow several programs to work at the same time and should be more stable.<br />
<br />
==Input==<br />
Buttons, keypad, touchscreen and [[nubs]] are all exposed through Linux event interface (EVDEV). All devices are represented by '''/dev/input/eventX''' files, which can be opened, read and queried (using ioctl calls). The reads can be synchronous (the read will only return when user does something, like presses the button), or asynchronous (the system will report what changed since the last time you asked).<br />
<br />
{{warning<br />
|Don't hardcode device filenames in your program!<br />
}}<br />
<br />
For example, currently /dev/input/event2 represents game buttons, but in future it may become touchscreen. Scan input device names instead, example:<br />
<source lang="c"><br />
for (i = 0; 1; i++)<br />
{<br />
sprintf(name, "/dev/input/event%i", i);<br />
fd = open(name, O_RDONLY);<br />
if (fd < 0) break; /* no more devices */<br />
ioctl(fd, EVIOCGNAME(sizeof(name)), name);<br />
if (strcmp(name, "gpio-keys") == 0)<br />
return fd; /* found the buttons! */<br />
close(fd); /* we don't need this device */<br />
}<br />
</source><br />
<br />
List of device names and events they send:<br />
{|class="wikitable"<br />
|-<br />
!name<br />
!description<br />
!event.type<br />
!event.code<br />
!event.value<br />
|-<br />
|keypad<br />
|keypad<br />
|EV_KEY<br />
|KEY_0...KEY_Z, KEY_BACKSPACE, KEY_LEFTSHIFT, KEY_SPACE, KEY_ENTER, KEY_COMMA, KEY_DOT, KEY_FN<br />
|0 - released<br> 1 - pressed<br> 2 - autorepeat event<br />
|-<br />
|gpio-keys<br />
|game buttons<br />
|EV_KEY<br />
|KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT, KEY_MENU (Pandora button), KEY_LEFTALT (Start), KEY_LEFTCTRL (Select), KEY_PAGEUP (Y/North), KEY_HOME (A/East), KEY_PAGEDOWN (X/South), KEY_END (B/West), KEY_RIGHTSHIFT (Shoulder L), KEY_RIGHTCTRL (Shoulder R), KEY_KPPLUS (Shoulder L2), KEY_KPMINUS (Shoulder R2), KEY_COFFEE (Hold)<br />
|0 - released<br> 1 - pressed<br />
|-<br />
|gpio-keys<br />
|lid state<br />
|EV_SW<br />
|SW_LID<br />
|0 - closing<br> 1 - opening<br />
|-<br />
|touchscreen<br />
|touchscreen<br />
|EV_ABS<br />
|ABS_X, ABS_Y, ABS_PRESSURE<br />
|varies, use calibration data<br />
|-<br />
|nub0<br />
|left nub<br />
|EV_ABS<br />
|ABS_X, ABS_Y<br />
| -256 (Left/Up)<br>0<br>+256 (Right/Down)<br />
|-<br />
|nub1<br />
|right nub<br />
|EV_ABS<br />
|ABS_X, ABS_Y<br />
| -256 (Left/Up))<br>0<br>+256 (Right/Down)<br />
|}<br />
<br />
Sample code:<br><br />
[http://beagleboard.googlecode.com/files/evtest.c evtest.c]<br />
[http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-misc.git;a=blob;f=op_test_inputs.c;hb=HEAD op_test_inputs.c]<br />
<br />
===Nubs===<br />
Nubs have 3 modes that can be switched during runtime: absolute, mouse, mbuttons; this can be done by writing one of those 3 strings to /proc/pandora/nubX/mode . On mode change /dev/input/event* device reenumeration starts and files belonging to nubs are recreated and must be reopened.<br />
<br />
<strong>Warning:</strong> it is not guaranteed that input files will finish recreating after a write to /proc/pandora/nubX/mode finishes, it is application's responsibility to wait until those files are available.<br />
<br />
To solve the above problem, the OS provides a helper script that will wait for enumeration to complete:<br />
<source lang="bash"><br />
/usr/pandora/scripts/op_nubchange.sh <left_num_mode> <right_nub_mode><br />
</source><br />
op_nubchange.sh is not available on HF6 or earlier firmwares, to support them, something like this could be used:<br />
<source lang="bash"><br />
if [ -e /usr/pandora/scripts/op_nubchange.sh ]; then<br />
/usr/pandora/scripts/op_nubchange.sh absolute absolute<br />
else<br />
echo absolute > /proc/pandora/nub0/mode<br />
echo absolute > /proc/pandora/nub1/mode<br />
fi<br />
</source><br />
<br />
===Touchscreen===<br />
Event interface returns uncalibrated values directly from driver, so you need to use tslib or manage calibration yourself (using data from /etc/pointercal).<br />
<br />
===X11===<br />
When using the direct kernel api for input, it is also important to stop X processing the events as well. To do this you can create an X window to eat the events. There is also a utility that comes with the Pandora to do this:<br />
<source lang="c"><br />
op_runfbapp ./yourapp<br />
</source><br />
<br />
==Sound==<br />
Pandora uses ALSA, but it has OSS emulation enabled too, so GP2X code should work.<br />
<br />
==Video==<br />
===Architecture===<br />
Framebuffer device (/dev/fbX) is supported. There are 3 framebuffers available ('''/dev/fb0''', /dev/fb1 and /dev/fb2), which represent 3 graphics/video layers on [[OMAP3]] by default (but can be reconfigured). Only /dev/fb0 is enabled by default.<br />
<br />
[[OMAP3]] display subsystem is controlled by a driver known as [[DSS2]], which has various controls available on /sys/devices/platform/omapdss/ (but they are not meant to be changed by programs, so they are root writable only). The driver exposes 3 layers (called overlays) and 2 displays. Overlays 1 and 2 can perform hardware scaling on the fly using 5-tap poly-phase filter, overlay0 can not. Displays 0 and 1 represent LCD and TV respectively. By default the 3 framebuffers (/dev/fbX) are redirected to 3 overlays, which all output to the LCD. This configuration is not meant to be changed by programs, only firmware should manage these.<br />
<br />
===Basic usage===<br />
====framebuffer interface====<br />
Framebuffers can be accessed Linux fbdev interface:<br />
<source lang="c"><br />
fbdev = open("/dev/fb0", O_RDWR);<br />
buffer = mmap(0, 800*480*2, PROT_READ | PROT_WRITE, MAP_SHARED, fbdev, 0);<br />
</source><br />
(this is basic example, no error checks)<br />
<br />
the returned pointer can be used to draw on the screen.<br />
<br />
Be sure to #include <linux/fb.h> to get access to the FB device ioctl interface, and <sys/ioctl.h> for access to ioctl itself.<br />
<br />
====double buffering====<br />
This can be achieved using FBIOPAN_DISPLAY ioctl system call. For this you need to mmap framebuffer of double size<br />
<source lang="c"><br />
buffer1 = mmap(0, 800*480*2 * 2, PROT_WRITE, MAP_SHARED, fbdev, 0);<br />
buffer2 = (char *)mem + 800*480*2;<br />
</source><br />
<br />
Then to display buffer2 you would call:<br />
<source lang="c"><br />
struct fb_var_screeninfo fbvar;<br />
ioctl(fbdev, FBIOGET_VSCREENINFO, &fbvar);<br />
fbvar.yoffset = 480;<br />
ioctl(fbdev, FBIOPAN_DISPLAY, &fbvar);<br />
</source><br />
going back to buffer1 would be repeating above with fbvar.yoffset = 0. Tripple or quad buffering can be implemented using the same technique.<br />
<br />
====vertical sync====<br />
Linux has standard FBIO_WAITFORVSYNC for this:<br />
<source lang="c"><br />
int arg = 0;<br />
ioctl(fbdev, FBIO_WAITFORVSYNC, &arg);<br />
</source><br />
be sure to pass argument value 0 or it will not work.<br />
<br />
Some toolchains don't have FBIO_WAITFORVSYNC defined in <linux/fb.h>, in which case you can define it in the following manner:<br />
<br />
<source lang="c"><br />
#ifndef FBIO_WAITFORVSYNC<br />
#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)<br />
#endif<br />
</source><br />
<br />
====hardware scaling====<br />
Overlay1 (/dev/fb1) can be used to achieve hardware scaling. Technically overlay2 (fb2) can be used for this too, but it is planned to be used by the system for TV-out functionality, so don't use it. The overlay is configured using series of standard and OMAP specific ioctl calls, but the system ships with some tools to achieve this from scripts too. This way the framebuffer can be set up for some arbitrary size (say 320x240) and can output to LCD as 800x480 with hardware scaling.<br />
Here is an example script:<br />
<source lang="bash"><br />
ofbset -fb /dev/fb1 -pos 0 0 -size 800 480 -mem 307200 -en 1<br />
fbset -fb /dev/fb1 -g 320 240 320 480 16<br />
<br />
./your_app_here<br />
<br />
ofbset -fb /dev/fb1 -pos 0 0 -size 0 0 -mem 0 -en 0<br />
</source><br />
<br />
What it does:<br />
* allocates OMAP DSS layer, asks video output to be 800x480 at position 0,0 (could set it to 640x480 at 80,0 instead to get centered 2x scaling of 320x240). 307200 bytes of video memory are allocated for 2 320x240 16bpp screens (for doublebuffering).<br />
* sets video mode to 320x240@16bpp, virtual resolution 320x480 for doublebuffering.<br />
* runs your app<br />
* cleans the video layer on exit<br />
<br />
Now the program can act as if it works with 320x240 16bpp screen.<br />
<br />
====LCD refresh rate====<br />
The OS has a dedicated script which can change the LCD refresh rate. It must be ran with sudo:<br />
<source lang="c"><br />
sudo -n /usr/pandora/scripts/op_lcdrate.sh 50<br />
</source><br />
From code, system() function can be used for this.<br />
<br />
'''Note''': this doesn't mean your program has to run as root to use this (it never should!), just run the script as shown above.<br />
<br />
====gamma====<br />
Since SZ 1.52, gamma can be controlled with another script, the same way as LCD refresh:<br />
<source lang="c"><br />
sudo -n /usr/pandora/scripts/op_gamma.sh 1.0<br />
</source><br />
where 1.0 is the gamma level. If supplied gamma level is 0, then user defaults are used (useful to set on exit). There is also an optional -b N argument (to be specified before gamma value), where N controls black level (0-255, useful to combat LCD ghosting).<br />
<br />
===Hardware scaling filter control===<br />
The hardware scaler in pandora uses poly-phase 5-tap 8-phase filter. It is described in 15.4.2.3.4 and 15.6.1.3 sections of TRM. There are 40 coefficients programmable for both horizontal and vertical resampling (vertical resampling might also use 3 taps/24 coefficients, it depends on available pixel clock).<br />
====using predefined filters====<br />
Just run 'sudo /usr/pandora/scripts/op_videofir.sh <name>', where name currently can be:<br />
* default - the default filter from OMAP manual<br />
* none - nearest neighbor<br />
====using custom filters====<br />
run 'sudo /usr/pandora/scripts/op_videofir.sh <basename>', where basename* files contains coefficient table. The script will look for <basename>_h, <basename>_v3 and <basename>_v5 files for 5-tap horizontal, 3-tap vertical and 5-tap vertical configurations respectively. Pass absolute or relative path for basename with './', like './something'. The coefficients should be in a form of table like described in TRM, for example:<br />
<source lang="c"><br />
----<br />
0 0 128 0 0<br />
-1 13 124 -8 0<br />
-2 30 112 -11 -1<br />
-5 51 95 -11 -2<br />
0 -9 73 73 -9<br />
-2 -11 95 51 -5<br />
-1 -11 112 30 -2<br />
0 -8 124 13 -1<br />
</source><br />
For 3-tap table, first and last columns should contain zeros.<br />
<br />
==LEDs and Display backlight==<br />
The LEDs can be controlled via '''/sys/class/leds/''', and then a file [http://www.gp32x.com/board/index.php?s=&showtopic=45309&view=findpost&p=673593]:<br />
* pandora::sd1<br />
* pandora::sd2<br />
* pandora::charger<br />
* pandora::power<br />
* pandora::bluetooth<br />
* pandora::wifi<br />
* pandora::keypad_bl<br />
Backlight can be controlled via '''/sys/class/backlight/'''.<br />
<br />
==Battery==<br />
There is bq27500 battery monitoring chip onboard, that exports various files at /sys/class/power_supply/bq27500-0/ , for example 'capacity' tells charge percenage left. See [[Data_provided_by_Battery_and_Power_driver]] for more details.<br><br />
There are also similar directories at /sys/class/power_supply/twl4030_* that provide info while charging.<br />
<br />
==Misc==<br />
===Overclocking===<br />
Can be performed by running a helper script<br />
<source lang="bash"><br />
sudo /usr/pandora/scripts/op_cpuspeed.sh X<br />
</source><br />
In case you want to do it from another program or non-interactively, you can use system() function (or similar) with:<br />
<source lang="bash"><br />
sudo -n /usr/pandora/scripts/op_cpuspeed.sh -n X<br />
</source><br />
* Note: you are advised not to change the clock explicitly from a program because optimal clock may differ on different pandora revisions, or somebody might want to run at different clock speed to save battery, CPU life, etc. . Let the user decide about the clock before running the program and set it using the system tools.<br />
* Note: '-n' script argument is not available on pre-SuperZaxxon Final firmwares.<br />
<br />
[[Category:Development]]<br />
[[Category:Kernel]]<br />
[[Category:Hardware]]</div>Lollahttps://pandorawiki.org/index.php?title=Kernel_interface&diff=29120Kernel interface2013-11-27T10:00:24Z<p>Lolla: </p>
<hr />
<div>{{hint|For apps use higher level libraries/interfaces like SDL, Qt, X or similar for your own good (portability). It may be impossible to retain this layout on some major hardware revision, let's say Pandora 3000, and your program will break. Also this requires some level of Linux programming knowledge.}}<br />
<br />
In case you need to write low level code (you can't/don't want to use high level libs like [[SDL]]), you can use kernel interface. This is the recommended way to access hardware (as opposed to GP2X style of accessing chip registers by mmap'ing /dev/mem), because in case hardware changes are needed in future, they could be handled by kernel and all programs would still work. It also should allow several programs to work at the same time and should be more stable.<br />
<br />
==Input==<br />
Buttons, keypad, touchscreen and [[nubs]] are all exposed through Linux event interface (EVDEV). All devices are represented by '''/dev/input/eventX''' files, which can be opened, read and queried (using ioctl calls). The reads can be synchronous (the read will only return when user does something, like presses the button), or asynchronous (the system will report what changed since the last time you asked).<br />
<br />
{{warning<br />
|Don't hardcode device filenames in your program!<br />
}}<br />
<br />
For example, currently /dev/input/event2 represents game buttons, but in future it may become touchscreen. Scan input device names instead, example:<br />
<source lang="c"><br />
for (i = 0; 1; i++)<br />
{<br />
sprintf(name, "/dev/input/event%i", i);<br />
fd = open(name, O_RDONLY);<br />
if (fd < 0) break; /* no more devices */<br />
ioctl(fd, EVIOCGNAME(sizeof(name)), name);<br />
if (strcmp(name, "gpio-keys") == 0)<br />
return fd; /* found the buttons! */<br />
close(fd); /* we don't need this device */<br />
}<br />
</source><br />
<br />
List of device names and events they send:<br />
{|class="wikitable"<br />
|-<br />
!name<br />
!description<br />
!event.type<br />
!event.code<br />
!event.value<br />
|-<br />
|keypad<br />
|keypad<br />
|EV_KEY<br />
|KEY_0...KEY_Z, KEY_BACKSPACE, KEY_LEFTSHIFT, KEY_SPACE, KEY_ENTER, KEY_COMMA, KEY_DOT, KEY_FN<br />
|0 - released<br> 1 - pressed<br> 2 - autorepeat event<br />
|-<br />
|gpio-keys<br />
|game buttons<br />
|EV_KEY<br />
|KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT, KEY_MENU (Pandora button), KEY_LEFTALT (Start), KEY_LEFTCTRL (Select), KEY_PAGEUP (Y/North), KEY_HOME (A/East), KEY_PAGEDOWN (X/South), KEY_END (B/West), KEY_RIGHTSHIFT (Shoulder L), KEY_RIGHTCTRL (Shoulder R), KEY_KPPLUS (Shoulder L2), KEY_KPMINUS (Shoulder R2), KEY_COFFEE (Hold)<br />
|0 - released<br> 1 - pressed<br />
|-<br />
|gpio-keys<br />
|lid state<br />
|EV_SW<br />
|SW_LID<br />
|0 - closing<br> 1 - opening<br />
|-<br />
|touchscreen<br />
|touchscreen<br />
|EV_ABS<br />
|ABS_X, ABS_Y, ABS_PRESSURE<br />
|varies, use calibration data<br />
|-<br />
|nub0<br />
|left nub<br />
|EV_ABS<br />
|ABS_X, ABS_Y<br />
| -256 (Left/Up)<br>0<br>+256 (Right/Down)<br />
|-<br />
|nub1<br />
|right nub<br />
|EV_ABS<br />
|ABS_X, ABS_Y<br />
| -256 (Left/Up))<br>0<br>+256 (Right/Down)<br />
|}<br />
<br />
Sample code:<br><br />
[http://beagleboard.googlecode.com/files/evtest.c evtest.c]<br />
[http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-misc.git;a=blob;f=op_test_inputs.c;hb=HEAD op_test_inputs.c]<br />
<br />
===Nubs===<br />
Nubs have 3 modes that can be switched during runtime: absolute, mouse, mbuttons; this can be done by writing one of those 3 strings to /proc/pandora/nubX/mode . On mode change /dev/input/event* device reenumeration starts and files belonging to nubs are recreated and must be reopened.<br />
<br />
<strong>Warning:</strong> it is not guaranteed that input files will finish recreating after a write to /proc/pandora/nubX/mode finishes, it is application's responsibility to wait until those files are available.<br />
<br />
To solve the above problem, the OS provides a helper script that will wait for enumeration to complete:<br />
<source lang="bash"><br />
/usr/pandora/scripts/op_nubchange.sh <left_num_mode> <right_nub_mode><br />
</source><br />
op_nubchange.sh is not available on HF6 or earlier firmwares, to support them, something like this could be used:<br />
<source lang="bash"><br />
if [ -e /usr/pandora/scripts/op_nubchange.sh ]; then<br />
/usr/pandora/scripts/op_nubchange.sh absolute absolute<br />
else<br />
echo absolute > /proc/pandora/nub0/mode<br />
echo absolute > /proc/pandora/nub1/mode<br />
fi<br />
</source><br />
<br />
===Touchscreen===<br />
Event interface returns uncalibrated values directly from driver, so you need to use tslib or manage calibration yourself (using data from /etc/pointercal).<br />
<br />
===X11===<br />
When using the direct kernel api for input, it is also important to stop X processing the events as well. To do this you can create an X window to eat the events. There is also a utility that comes with the Pandora to do this:<br />
<source lang="c"><br />
op_runfbapp ./yourapp<br />
</source><br />
<br />
==Sound==<br />
Pandora uses [[ALSA]], but it has [[OSS]] emulation enabled too, so [[GP2X]] code should work.<br />
<br />
==Video==<br />
===Architecture===<br />
Framebuffer device (/dev/fbX) is supported. There are 3 framebuffers available ('''/dev/fb0''', /dev/fb1 and /dev/fb2), which represent 3 graphics/video layers on [[OMAP3]] by default (but can be reconfigured). Only /dev/fb0 is enabled by default.<br />
<br />
[[OMAP3]] display subsystem is controlled by a driver known as [[DSS2]], which has various controls available on /sys/devices/platform/omapdss/ (but they are not meant to be changed by programs, so they are root writable only). The driver exposes 3 layers (called overlays) and 2 displays. Overlays 1 and 2 can perform hardware scaling on the fly using 5-tap poly-phase filter, overlay0 can not. Displays 0 and 1 represent LCD and TV respectively. By default the 3 framebuffers (/dev/fbX) are redirected to 3 overlays, which all output to the LCD. This configuration is not meant to be changed by programs, only firmware should manage these.<br />
<br />
===Basic usage===<br />
====framebuffer interface====<br />
Framebuffers can be accessed Linux fbdev interface:<br />
<source lang="c"><br />
fbdev = open("/dev/fb0", O_RDWR);<br />
buffer = mmap(0, 800*480*2, PROT_READ | PROT_WRITE, MAP_SHARED, fbdev, 0);<br />
</source><br />
(this is basic example, no error checks)<br />
<br />
the returned pointer can be used to draw on the screen.<br />
<br />
Be sure to #include <linux/fb.h> to get access to the FB device ioctl interface, and <sys/ioctl.h> for access to ioctl itself.<br />
<br />
====double buffering====<br />
This can be achieved using FBIOPAN_DISPLAY ioctl system call. For this you need to mmap framebuffer of double size<br />
<source lang="c"><br />
buffer1 = mmap(0, 800*480*2 * 2, PROT_WRITE, MAP_SHARED, fbdev, 0);<br />
buffer2 = (char *)mem + 800*480*2;<br />
</source><br />
<br />
Then to display buffer2 you would call:<br />
<source lang="c"><br />
struct fb_var_screeninfo fbvar;<br />
ioctl(fbdev, FBIOGET_VSCREENINFO, &fbvar);<br />
fbvar.yoffset = 480;<br />
ioctl(fbdev, FBIOPAN_DISPLAY, &fbvar);<br />
</source><br />
going back to buffer1 would be repeating above with fbvar.yoffset = 0. Tripple or quad buffering can be implemented using the same technique.<br />
<br />
====vertical sync====<br />
Linux has standard FBIO_WAITFORVSYNC for this:<br />
<source lang="c"><br />
int arg = 0;<br />
ioctl(fbdev, FBIO_WAITFORVSYNC, &arg);<br />
</source><br />
be sure to pass argument value 0 or it will not work.<br />
<br />
Some toolchains don't have FBIO_WAITFORVSYNC defined in <linux/fb.h>, in which case you can define it in the following manner:<br />
<br />
<source lang="c"><br />
#ifndef FBIO_WAITFORVSYNC<br />
#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)<br />
#endif<br />
</source><br />
<br />
====hardware scaling====<br />
Overlay1 (/dev/fb1) can be used to achieve hardware scaling. Technically overlay2 (fb2) can be used for this too, but it is planned to be used by the system for TV-out functionality, so don't use it. The overlay is configured using series of standard and OMAP specific ioctl calls, but the system ships with some tools to achieve this from scripts too. This way the framebuffer can be set up for some arbitrary size (say 320x240) and can output to LCD as 800x480 with hardware scaling.<br />
Here is an example script:<br />
<source lang="bash"><br />
ofbset -fb /dev/fb1 -pos 0 0 -size 800 480 -mem 307200 -en 1<br />
fbset -fb /dev/fb1 -g 320 240 320 480 16<br />
<br />
./your_app_here<br />
<br />
ofbset -fb /dev/fb1 -pos 0 0 -size 0 0 -mem 0 -en 0<br />
</source><br />
<br />
What it does:<br />
* allocates OMAP DSS layer, asks video output to be 800x480 at position 0,0 (could set it to 640x480 at 80,0 instead to get centered 2x scaling of 320x240). 307200 bytes of video memory are allocated for 2 320x240 16bpp screens (for doublebuffering).<br />
* sets video mode to 320x240@16bpp, virtual resolution 320x480 for doublebuffering.<br />
* runs your app<br />
* cleans the video layer on exit<br />
<br />
Now the program can act as if it works with 320x240 16bpp screen.<br />
<br />
====LCD refresh rate====<br />
The OS has a dedicated script which can change the LCD refresh rate. It must be ran with sudo:<br />
<source lang="c"><br />
sudo -n /usr/pandora/scripts/op_lcdrate.sh 50<br />
</source><br />
From code, system() function can be used for this.<br />
<br />
'''Note''': this doesn't mean your program has to run as root to use this (it never should!), just run the script as shown above.<br />
<br />
====gamma====<br />
Since SZ 1.52, gamma can be controlled with another script, the same way as LCD refresh:<br />
<source lang="c"><br />
sudo -n /usr/pandora/scripts/op_gamma.sh 1.0<br />
</source><br />
where 1.0 is the gamma level. If supplied gamma level is 0, then user defaults are used (useful to set on exit). There is also an optional -b N argument (to be specified before gamma value), where N controls black level (0-255, useful to combat LCD ghosting).<br />
<br />
===Hardware scaling filter control===<br />
The hardware scaler in pandora uses poly-phase 5-tap 8-phase filter. It is described in 15.4.2.3.4 and 15.6.1.3 sections of TRM. There are 40 coefficients programmable for both horizontal and vertical resampling (vertical resampling might also use 3 taps/24 coefficients, it depends on available pixel clock).<br />
====using predefined filters====<br />
Just run 'sudo /usr/pandora/scripts/op_videofir.sh <name>', where name currently can be:<br />
* default - the default filter from OMAP manual<br />
* none - nearest neighbor<br />
====using custom filters====<br />
run 'sudo /usr/pandora/scripts/op_videofir.sh <basename>', where basename* files contains coefficient table. The script will look for <basename>_h, <basename>_v3 and <basename>_v5 files for 5-tap horizontal, 3-tap vertical and 5-tap vertical configurations respectively. Pass absolute or relative path for basename with './', like './something'. The coefficients should be in a form of table like described in TRM, for example:<br />
<source lang="c"><br />
----<br />
0 0 128 0 0<br />
-1 13 124 -8 0<br />
-2 30 112 -11 -1<br />
-5 51 95 -11 -2<br />
0 -9 73 73 -9<br />
-2 -11 95 51 -5<br />
-1 -11 112 30 -2<br />
0 -8 124 13 -1<br />
</source><br />
For 3-tap table, first and last columns should contain zeros.<br />
<br />
==LEDs and Display backlight==<br />
The LEDs can be controlled via '''/sys/class/leds/''', and then a file [http://www.gp32x.com/board/index.php?s=&showtopic=45309&view=findpost&p=673593]:<br />
* pandora::sd1<br />
* pandora::sd2<br />
* pandora::charger<br />
* pandora::power<br />
* pandora::bluetooth<br />
* pandora::wifi<br />
* pandora::keypad_bl<br />
Backlight can be controlled via '''/sys/class/backlight/'''.<br />
<br />
==Battery==<br />
There is bq27500 battery monitoring chip onboard, that exports various files at /sys/class/power_supply/bq27500-0/ , for example 'capacity' tells charge percenage left. See [[Data_provided_by_Battery_and_Power_driver]] for more details.<br><br />
There are also similar directories at /sys/class/power_supply/twl4030_* that provide info while charging.<br />
<br />
==Misc==<br />
===Overclocking===<br />
Can be performed by running a helper script<br />
<source lang="bash"><br />
sudo /usr/pandora/scripts/op_cpuspeed.sh X<br />
</source><br />
In case you want to do it from another program or non-interactively, you can use system() function (or similar) with:<br />
<source lang="bash"><br />
sudo -n /usr/pandora/scripts/op_cpuspeed.sh -n X<br />
</source><br />
* Note: you are advised not to change the clock explicitly from a program because optimal clock may differ on different pandora revisions, or somebody might want to run at different clock speed to save battery, CPU life, etc. . Let the user decide about the clock before running the program and set it using the system tools.<br />
* Note: '-n' script argument is not available on pre-SuperZaxxon Final firmwares.<br />
<br />
[[Category:Development]]<br />
[[Category:Kernel]]<br />
[[Category:Hardware]]</div>Lollahttps://pandorawiki.org/index.php?title=Kernel_interface&diff=29119Kernel interface2013-11-27T09:58:37Z<p>Lolla: </p>
<hr />
<div>{{hint|For apps use higher level libraries/interfaces like SDL, Qt, X or similar for your own good (portability). It may be impossible to retain this layout on some major hardware revision, let's say Pandora 3000, and your program will break. Also this requires some level of Linux programming knowledge.}}<br />
<br />
In case you need to write low level code (you can't/don't want to use high level libs like [[SDL]]), you can use kernel interface. This is the recommended way to access hardware (as opposed to GP2X style of accessing chip registers by mmap'ing /dev/mem), because in case hardware changes are needed in future, they could be handled by kernel and all programs would still work. It also should allow several programs to work at the same time and should be more stable.<br />
<br />
==Input==<br />
[[Buttons]], [[keypad]], [[touchscreen]] and [[nubs]] are all exposed through Linux event interface (EVDEV). All devices are represented by '''/dev/input/eventX''' files, which can be opened, read and queried (using ioctl calls). The reads can be synchronous (the read will only return when user does something, like presses the button), or asynchronous (the system will report what changed since the last time you asked).<br />
<br />
{{warning<br />
|Don't hardcode device filenames in your program!<br />
}}<br />
<br />
For example, currently /dev/input/event2 represents game buttons, but in future it may become touchscreen. Scan input device names instead, example:<br />
<source lang="c"><br />
for (i = 0; 1; i++)<br />
{<br />
sprintf(name, "/dev/input/event%i", i);<br />
fd = open(name, O_RDONLY);<br />
if (fd < 0) break; /* no more devices */<br />
ioctl(fd, EVIOCGNAME(sizeof(name)), name);<br />
if (strcmp(name, "gpio-keys") == 0)<br />
return fd; /* found the buttons! */<br />
close(fd); /* we don't need this device */<br />
}<br />
</source><br />
<br />
List of device names and events they send:<br />
{|class="wikitable"<br />
|-<br />
!name<br />
!description<br />
!event.type<br />
!event.code<br />
!event.value<br />
|-<br />
|keypad<br />
|keypad<br />
|EV_KEY<br />
|KEY_0...KEY_Z, KEY_BACKSPACE, KEY_LEFTSHIFT, KEY_SPACE, KEY_ENTER, KEY_COMMA, KEY_DOT, KEY_FN<br />
|0 - released<br> 1 - pressed<br> 2 - autorepeat event<br />
|-<br />
|gpio-keys<br />
|game buttons<br />
|EV_KEY<br />
|KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT, KEY_MENU (Pandora button), KEY_LEFTALT (Start), KEY_LEFTCTRL (Select), KEY_PAGEUP (Y/North), KEY_HOME (A/East), KEY_PAGEDOWN (X/South), KEY_END (B/West), KEY_RIGHTSHIFT (Shoulder L), KEY_RIGHTCTRL (Shoulder R), KEY_KPPLUS (Shoulder L2), KEY_KPMINUS (Shoulder R2), KEY_COFFEE (Hold)<br />
|0 - released<br> 1 - pressed<br />
|-<br />
|gpio-keys<br />
|lid state<br />
|EV_SW<br />
|SW_LID<br />
|0 - closing<br> 1 - opening<br />
|-<br />
|touchscreen<br />
|touchscreen<br />
|EV_ABS<br />
|ABS_X, ABS_Y, ABS_PRESSURE<br />
|varies, use calibration data<br />
|-<br />
|nub0<br />
|left nub<br />
|EV_ABS<br />
|ABS_X, ABS_Y<br />
| -256 (Left/Up)<br>0<br>+256 (Right/Down)<br />
|-<br />
|nub1<br />
|right nub<br />
|EV_ABS<br />
|ABS_X, ABS_Y<br />
| -256 (Left/Up))<br>0<br>+256 (Right/Down)<br />
|}<br />
<br />
Sample code:<br><br />
[http://beagleboard.googlecode.com/files/evtest.c evtest.c]<br />
[http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-misc.git;a=blob;f=op_test_inputs.c;hb=HEAD op_test_inputs.c]<br />
<br />
===Nubs===<br />
Nubs have 3 modes that can be switched during runtime: absolute, mouse, mbuttons; this can be done by writing one of those 3 strings to /proc/pandora/nubX/mode . On mode change /dev/input/event* device reenumeration starts and files belonging to nubs are recreated and must be reopened.<br />
<br />
<strong>Warning:</strong> it is not guaranteed that input files will finish recreating after a write to /proc/pandora/nubX/mode finishes, it is application's responsibility to wait until those files are available.<br />
<br />
To solve the above problem, the OS provides a helper script that will wait for enumeration to complete:<br />
<source lang="bash"><br />
/usr/pandora/scripts/op_nubchange.sh <left_num_mode> <right_nub_mode><br />
</source><br />
op_nubchange.sh is not available on HF6 or earlier firmwares, to support them, something like this could be used:<br />
<source lang="bash"><br />
if [ -e /usr/pandora/scripts/op_nubchange.sh ]; then<br />
/usr/pandora/scripts/op_nubchange.sh absolute absolute<br />
else<br />
echo absolute > /proc/pandora/nub0/mode<br />
echo absolute > /proc/pandora/nub1/mode<br />
fi<br />
</source><br />
<br />
===Touchscreen===<br />
Event interface returns uncalibrated values directly from driver, so you need to use tslib or manage calibration yourself (using data from /etc/pointercal).<br />
<br />
===X11===<br />
When using the direct kernel api for input, it is also important to stop X processing the events as well. To do this you can create an X window to eat the events. There is also a utility that comes with the Pandora to do this:<br />
<source lang="c"><br />
op_runfbapp ./yourapp<br />
</source><br />
<br />
==Sound==<br />
Pandora uses [[ALSA]], but it has [[OSS]] emulation enabled too, so [[GP2X]] code should work.<br />
<br />
==Video==<br />
===Architecture===<br />
Framebuffer device (/dev/fbX) is supported. There are 3 framebuffers available ('''/dev/fb0''', /dev/fb1 and /dev/fb2), which represent 3 graphics/video layers on [[OMAP3]] by default (but can be reconfigured). Only /dev/fb0 is enabled by default.<br />
<br />
[[OMAP3]] display subsystem is controlled by a driver known as [[DSS2]], which has various controls available on /sys/devices/platform/omapdss/ (but they are not meant to be changed by programs, so they are root writable only). The driver exposes 3 layers (called overlays) and 2 displays. Overlays 1 and 2 can perform hardware scaling on the fly using 5-tap poly-phase filter, overlay0 can not. Displays 0 and 1 represent LCD and TV respectively. By default the 3 framebuffers (/dev/fbX) are redirected to 3 overlays, which all output to the LCD. This configuration is not meant to be changed by programs, only firmware should manage these.<br />
<br />
===Basic usage===<br />
====framebuffer interface====<br />
Framebuffers can be accessed Linux fbdev interface:<br />
<source lang="c"><br />
fbdev = open("/dev/fb0", O_RDWR);<br />
buffer = mmap(0, 800*480*2, PROT_READ | PROT_WRITE, MAP_SHARED, fbdev, 0);<br />
</source><br />
(this is basic example, no error checks)<br />
<br />
the returned pointer can be used to draw on the screen.<br />
<br />
Be sure to #include <linux/fb.h> to get access to the FB device ioctl interface, and <sys/ioctl.h> for access to ioctl itself.<br />
<br />
====double buffering====<br />
This can be achieved using FBIOPAN_DISPLAY ioctl system call. For this you need to mmap framebuffer of double size<br />
<source lang="c"><br />
buffer1 = mmap(0, 800*480*2 * 2, PROT_WRITE, MAP_SHARED, fbdev, 0);<br />
buffer2 = (char *)mem + 800*480*2;<br />
</source><br />
<br />
Then to display buffer2 you would call:<br />
<source lang="c"><br />
struct fb_var_screeninfo fbvar;<br />
ioctl(fbdev, FBIOGET_VSCREENINFO, &fbvar);<br />
fbvar.yoffset = 480;<br />
ioctl(fbdev, FBIOPAN_DISPLAY, &fbvar);<br />
</source><br />
going back to buffer1 would be repeating above with fbvar.yoffset = 0. Tripple or quad buffering can be implemented using the same technique.<br />
<br />
====vertical sync====<br />
Linux has standard FBIO_WAITFORVSYNC for this:<br />
<source lang="c"><br />
int arg = 0;<br />
ioctl(fbdev, FBIO_WAITFORVSYNC, &arg);<br />
</source><br />
be sure to pass argument value 0 or it will not work.<br />
<br />
Some toolchains don't have FBIO_WAITFORVSYNC defined in <linux/fb.h>, in which case you can define it in the following manner:<br />
<br />
<source lang="c"><br />
#ifndef FBIO_WAITFORVSYNC<br />
#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)<br />
#endif<br />
</source><br />
<br />
====hardware scaling====<br />
Overlay1 (/dev/fb1) can be used to achieve hardware scaling. Technically overlay2 (fb2) can be used for this too, but it is planned to be used by the system for TV-out functionality, so don't use it. The overlay is configured using series of standard and OMAP specific ioctl calls, but the system ships with some tools to achieve this from scripts too. This way the framebuffer can be set up for some arbitrary size (say 320x240) and can output to LCD as 800x480 with hardware scaling.<br />
Here is an example script:<br />
<source lang="bash"><br />
ofbset -fb /dev/fb1 -pos 0 0 -size 800 480 -mem 307200 -en 1<br />
fbset -fb /dev/fb1 -g 320 240 320 480 16<br />
<br />
./your_app_here<br />
<br />
ofbset -fb /dev/fb1 -pos 0 0 -size 0 0 -mem 0 -en 0<br />
</source><br />
<br />
What it does:<br />
* allocates OMAP DSS layer, asks video output to be 800x480 at position 0,0 (could set it to 640x480 at 80,0 instead to get centered 2x scaling of 320x240). 307200 bytes of video memory are allocated for 2 320x240 16bpp screens (for doublebuffering).<br />
* sets video mode to 320x240@16bpp, virtual resolution 320x480 for doublebuffering.<br />
* runs your app<br />
* cleans the video layer on exit<br />
<br />
Now the program can act as if it works with 320x240 16bpp screen.<br />
<br />
====LCD refresh rate====<br />
The OS has a dedicated script which can change the LCD refresh rate. It must be ran with sudo:<br />
<source lang="c"><br />
sudo -n /usr/pandora/scripts/op_lcdrate.sh 50<br />
</source><br />
From code, system() function can be used for this.<br />
<br />
'''Note''': this doesn't mean your program has to run as root to use this (it never should!), just run the script as shown above.<br />
<br />
====gamma====<br />
Since SZ 1.52, gamma can be controlled with another script, the same way as LCD refresh:<br />
<source lang="c"><br />
sudo -n /usr/pandora/scripts/op_gamma.sh 1.0<br />
</source><br />
where 1.0 is the gamma level. If supplied gamma level is 0, then user defaults are used (useful to set on exit). There is also an optional -b N argument (to be specified before gamma value), where N controls black level (0-255, useful to combat LCD ghosting).<br />
<br />
===Hardware scaling filter control===<br />
The hardware scaler in pandora uses poly-phase 5-tap 8-phase filter. It is described in 15.4.2.3.4 and 15.6.1.3 sections of TRM. There are 40 coefficients programmable for both horizontal and vertical resampling (vertical resampling might also use 3 taps/24 coefficients, it depends on available pixel clock).<br />
====using predefined filters====<br />
Just run 'sudo /usr/pandora/scripts/op_videofir.sh <name>', where name currently can be:<br />
* default - the default filter from OMAP manual<br />
* none - nearest neighbor<br />
====using custom filters====<br />
run 'sudo /usr/pandora/scripts/op_videofir.sh <basename>', where basename* files contains coefficient table. The script will look for <basename>_h, <basename>_v3 and <basename>_v5 files for 5-tap horizontal, 3-tap vertical and 5-tap vertical configurations respectively. Pass absolute or relative path for basename with './', like './something'. The coefficients should be in a form of table like described in TRM, for example:<br />
<source lang="c"><br />
----<br />
0 0 128 0 0<br />
-1 13 124 -8 0<br />
-2 30 112 -11 -1<br />
-5 51 95 -11 -2<br />
0 -9 73 73 -9<br />
-2 -11 95 51 -5<br />
-1 -11 112 30 -2<br />
0 -8 124 13 -1<br />
</source><br />
For 3-tap table, first and last columns should contain zeros.<br />
<br />
==LEDs and Display backlight==<br />
The LEDs can be controlled via '''/sys/class/leds/''', and then a file [http://www.gp32x.com/board/index.php?s=&showtopic=45309&view=findpost&p=673593]:<br />
* pandora::sd1<br />
* pandora::sd2<br />
* pandora::charger<br />
* pandora::power<br />
* pandora::bluetooth<br />
* pandora::wifi<br />
* pandora::keypad_bl<br />
Backlight can be controlled via '''/sys/class/backlight/'''.<br />
<br />
==Battery==<br />
There is bq27500 battery monitoring chip onboard, that exports various files at /sys/class/power_supply/bq27500-0/ , for example 'capacity' tells charge percenage left. See [[Data_provided_by_Battery_and_Power_driver]] for more details.<br><br />
There are also similar directories at /sys/class/power_supply/twl4030_* that provide info while charging.<br />
<br />
==Misc==<br />
===Overclocking===<br />
Can be performed by running a helper script<br />
<source lang="bash"><br />
sudo /usr/pandora/scripts/op_cpuspeed.sh X<br />
</source><br />
In case you want to do it from another program or non-interactively, you can use system() function (or similar) with:<br />
<source lang="bash"><br />
sudo -n /usr/pandora/scripts/op_cpuspeed.sh -n X<br />
</source><br />
* Note: you are advised not to change the clock explicitly from a program because optimal clock may differ on different pandora revisions, or somebody might want to run at different clock speed to save battery, CPU life, etc. . Let the user decide about the clock before running the program and set it using the system tools.<br />
* Note: '-n' script argument is not available on pre-SuperZaxxon Final firmwares.<br />
<br />
[[Category:Development]]<br />
[[Category:Kernel]]<br />
[[Category:Hardware]]</div>Lollahttps://pandorawiki.org/index.php?title=Kernel_interface&diff=29118Kernel interface2013-11-27T09:57:36Z<p>Lolla: </p>
<hr />
<div>{{hint|For apps use higher level libraries/interfaces like SDL, Qt, X or similar for your own good (portability). It may be impossible to retain this layout on some major hardware revision, let's say Pandora 3000, and your program will break. Also this requires some level of Linux programming knowledge.}}<br />
<br />
In case you need to write low level code (you can't/don't want to use high level libs like [[SDL]]), you can use [[kernel]] interface. This is the recommended way to access hardware (as opposed to GP2X style of accessing chip registers by mmap'ing /dev/mem), because in case hardware changes are needed in future, they could be handled by kernel and all programs would still work. It also should allow several programs to work at the same time and should be more stable.<br />
<br />
==Input==<br />
[[Buttons]], [[keypad]], [[touchscreen]] and [[nubs]] are all exposed through Linux event interface (EVDEV). All devices are represented by '''/dev/input/eventX''' files, which can be opened, read and queried (using ioctl calls). The reads can be synchronous (the read will only return when user does something, like presses the button), or asynchronous (the system will report what changed since the last time you asked).<br />
<br />
{{warning<br />
|Don't hardcode device filenames in your program!<br />
}}<br />
<br />
For example, currently /dev/input/event2 represents game buttons, but in future it may become touchscreen. Scan input device names instead, example:<br />
<source lang="c"><br />
for (i = 0; 1; i++)<br />
{<br />
sprintf(name, "/dev/input/event%i", i);<br />
fd = open(name, O_RDONLY);<br />
if (fd < 0) break; /* no more devices */<br />
ioctl(fd, EVIOCGNAME(sizeof(name)), name);<br />
if (strcmp(name, "gpio-keys") == 0)<br />
return fd; /* found the buttons! */<br />
close(fd); /* we don't need this device */<br />
}<br />
</source><br />
<br />
List of device names and events they send:<br />
{|class="wikitable"<br />
|-<br />
!name<br />
!description<br />
!event.type<br />
!event.code<br />
!event.value<br />
|-<br />
|keypad<br />
|keypad<br />
|EV_KEY<br />
|KEY_0...KEY_Z, KEY_BACKSPACE, KEY_LEFTSHIFT, KEY_SPACE, KEY_ENTER, KEY_COMMA, KEY_DOT, KEY_FN<br />
|0 - released<br> 1 - pressed<br> 2 - autorepeat event<br />
|-<br />
|gpio-keys<br />
|game buttons<br />
|EV_KEY<br />
|KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT, KEY_MENU (Pandora button), KEY_LEFTALT (Start), KEY_LEFTCTRL (Select), KEY_PAGEUP (Y/North), KEY_HOME (A/East), KEY_PAGEDOWN (X/South), KEY_END (B/West), KEY_RIGHTSHIFT (Shoulder L), KEY_RIGHTCTRL (Shoulder R), KEY_KPPLUS (Shoulder L2), KEY_KPMINUS (Shoulder R2), KEY_COFFEE (Hold)<br />
|0 - released<br> 1 - pressed<br />
|-<br />
|gpio-keys<br />
|lid state<br />
|EV_SW<br />
|SW_LID<br />
|0 - closing<br> 1 - opening<br />
|-<br />
|touchscreen<br />
|touchscreen<br />
|EV_ABS<br />
|ABS_X, ABS_Y, ABS_PRESSURE<br />
|varies, use calibration data<br />
|-<br />
|nub0<br />
|left nub<br />
|EV_ABS<br />
|ABS_X, ABS_Y<br />
| -256 (Left/Up)<br>0<br>+256 (Right/Down)<br />
|-<br />
|nub1<br />
|right nub<br />
|EV_ABS<br />
|ABS_X, ABS_Y<br />
| -256 (Left/Up))<br>0<br>+256 (Right/Down)<br />
|}<br />
<br />
Sample code:<br><br />
[http://beagleboard.googlecode.com/files/evtest.c evtest.c]<br />
[http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-misc.git;a=blob;f=op_test_inputs.c;hb=HEAD op_test_inputs.c]<br />
<br />
===Nubs===<br />
Nubs have 3 modes that can be switched during runtime: absolute, mouse, mbuttons; this can be done by writing one of those 3 strings to /proc/pandora/nubX/mode . On mode change /dev/input/event* device reenumeration starts and files belonging to nubs are recreated and must be reopened.<br />
<br />
<strong>Warning:</strong> it is not guaranteed that input files will finish recreating after a write to /proc/pandora/nubX/mode finishes, it is application's responsibility to wait until those files are available.<br />
<br />
To solve the above problem, the OS provides a helper script that will wait for enumeration to complete:<br />
<source lang="bash"><br />
/usr/pandora/scripts/op_nubchange.sh <left_num_mode> <right_nub_mode><br />
</source><br />
op_nubchange.sh is not available on HF6 or earlier firmwares, to support them, something like this could be used:<br />
<source lang="bash"><br />
if [ -e /usr/pandora/scripts/op_nubchange.sh ]; then<br />
/usr/pandora/scripts/op_nubchange.sh absolute absolute<br />
else<br />
echo absolute > /proc/pandora/nub0/mode<br />
echo absolute > /proc/pandora/nub1/mode<br />
fi<br />
</source><br />
<br />
===Touchscreen===<br />
Event interface returns uncalibrated values directly from driver, so you need to use tslib or manage calibration yourself (using data from /etc/pointercal).<br />
<br />
===X11===<br />
When using the direct kernel api for input, it is also important to stop X processing the events as well. To do this you can create an X window to eat the events. There is also a utility that comes with the Pandora to do this:<br />
<source lang="c"><br />
op_runfbapp ./yourapp<br />
</source><br />
<br />
==Sound==<br />
Pandora uses [[ALSA]], but it has [[OSS]] emulation enabled too, so [[GP2X]] code should work.<br />
<br />
==Video==<br />
===Architecture===<br />
Framebuffer device (/dev/fbX) is supported. There are 3 framebuffers available ('''/dev/fb0''', /dev/fb1 and /dev/fb2), which represent 3 graphics/video layers on [[OMAP3]] by default (but can be reconfigured). Only /dev/fb0 is enabled by default.<br />
<br />
[[OMAP3]] display subsystem is controlled by a driver known as [[DSS2]], which has various controls available on /sys/devices/platform/omapdss/ (but they are not meant to be changed by programs, so they are root writable only). The driver exposes 3 layers (called overlays) and 2 displays. Overlays 1 and 2 can perform hardware scaling on the fly using 5-tap poly-phase filter, overlay0 can not. Displays 0 and 1 represent LCD and TV respectively. By default the 3 framebuffers (/dev/fbX) are redirected to 3 overlays, which all output to the LCD. This configuration is not meant to be changed by programs, only firmware should manage these.<br />
<br />
===Basic usage===<br />
====framebuffer interface====<br />
Framebuffers can be accessed Linux fbdev interface:<br />
<source lang="c"><br />
fbdev = open("/dev/fb0", O_RDWR);<br />
buffer = mmap(0, 800*480*2, PROT_READ | PROT_WRITE, MAP_SHARED, fbdev, 0);<br />
</source><br />
(this is basic example, no error checks)<br />
<br />
the returned pointer can be used to draw on the screen.<br />
<br />
Be sure to #include <linux/fb.h> to get access to the FB device ioctl interface, and <sys/ioctl.h> for access to ioctl itself.<br />
<br />
====double buffering====<br />
This can be achieved using FBIOPAN_DISPLAY ioctl system call. For this you need to mmap framebuffer of double size<br />
<source lang="c"><br />
buffer1 = mmap(0, 800*480*2 * 2, PROT_WRITE, MAP_SHARED, fbdev, 0);<br />
buffer2 = (char *)mem + 800*480*2;<br />
</source><br />
<br />
Then to display buffer2 you would call:<br />
<source lang="c"><br />
struct fb_var_screeninfo fbvar;<br />
ioctl(fbdev, FBIOGET_VSCREENINFO, &fbvar);<br />
fbvar.yoffset = 480;<br />
ioctl(fbdev, FBIOPAN_DISPLAY, &fbvar);<br />
</source><br />
going back to buffer1 would be repeating above with fbvar.yoffset = 0. Tripple or quad buffering can be implemented using the same technique.<br />
<br />
====vertical sync====<br />
Linux has standard FBIO_WAITFORVSYNC for this:<br />
<source lang="c"><br />
int arg = 0;<br />
ioctl(fbdev, FBIO_WAITFORVSYNC, &arg);<br />
</source><br />
be sure to pass argument value 0 or it will not work.<br />
<br />
Some toolchains don't have FBIO_WAITFORVSYNC defined in <linux/fb.h>, in which case you can define it in the following manner:<br />
<br />
<source lang="c"><br />
#ifndef FBIO_WAITFORVSYNC<br />
#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)<br />
#endif<br />
</source><br />
<br />
====hardware scaling====<br />
Overlay1 (/dev/fb1) can be used to achieve hardware scaling. Technically overlay2 (fb2) can be used for this too, but it is planned to be used by the system for TV-out functionality, so don't use it. The overlay is configured using series of standard and OMAP specific ioctl calls, but the system ships with some tools to achieve this from scripts too. This way the framebuffer can be set up for some arbitrary size (say 320x240) and can output to LCD as 800x480 with hardware scaling.<br />
Here is an example script:<br />
<source lang="bash"><br />
ofbset -fb /dev/fb1 -pos 0 0 -size 800 480 -mem 307200 -en 1<br />
fbset -fb /dev/fb1 -g 320 240 320 480 16<br />
<br />
./your_app_here<br />
<br />
ofbset -fb /dev/fb1 -pos 0 0 -size 0 0 -mem 0 -en 0<br />
</source><br />
<br />
What it does:<br />
* allocates OMAP DSS layer, asks video output to be 800x480 at position 0,0 (could set it to 640x480 at 80,0 instead to get centered 2x scaling of 320x240). 307200 bytes of video memory are allocated for 2 320x240 16bpp screens (for doublebuffering).<br />
* sets video mode to 320x240@16bpp, virtual resolution 320x480 for doublebuffering.<br />
* runs your app<br />
* cleans the video layer on exit<br />
<br />
Now the program can act as if it works with 320x240 16bpp screen.<br />
<br />
====LCD refresh rate====<br />
The OS has a dedicated script which can change the LCD refresh rate. It must be ran with sudo:<br />
<source lang="c"><br />
sudo -n /usr/pandora/scripts/op_lcdrate.sh 50<br />
</source><br />
From code, system() function can be used for this.<br />
<br />
'''Note''': this doesn't mean your program has to run as root to use this (it never should!), just run the script as shown above.<br />
<br />
====gamma====<br />
Since SZ 1.52, gamma can be controlled with another script, the same way as LCD refresh:<br />
<source lang="c"><br />
sudo -n /usr/pandora/scripts/op_gamma.sh 1.0<br />
</source><br />
where 1.0 is the gamma level. If supplied gamma level is 0, then user defaults are used (useful to set on exit). There is also an optional -b N argument (to be specified before gamma value), where N controls black level (0-255, useful to combat LCD ghosting).<br />
<br />
===Hardware scaling filter control===<br />
The hardware scaler in pandora uses poly-phase 5-tap 8-phase filter. It is described in 15.4.2.3.4 and 15.6.1.3 sections of TRM. There are 40 coefficients programmable for both horizontal and vertical resampling (vertical resampling might also use 3 taps/24 coefficients, it depends on available pixel clock).<br />
====using predefined filters====<br />
Just run 'sudo /usr/pandora/scripts/op_videofir.sh <name>', where name currently can be:<br />
* default - the default filter from OMAP manual<br />
* none - nearest neighbor<br />
====using custom filters====<br />
run 'sudo /usr/pandora/scripts/op_videofir.sh <basename>', where basename* files contains coefficient table. The script will look for <basename>_h, <basename>_v3 and <basename>_v5 files for 5-tap horizontal, 3-tap vertical and 5-tap vertical configurations respectively. Pass absolute or relative path for basename with './', like './something'. The coefficients should be in a form of table like described in TRM, for example:<br />
<source lang="c"><br />
----<br />
0 0 128 0 0<br />
-1 13 124 -8 0<br />
-2 30 112 -11 -1<br />
-5 51 95 -11 -2<br />
0 -9 73 73 -9<br />
-2 -11 95 51 -5<br />
-1 -11 112 30 -2<br />
0 -8 124 13 -1<br />
</source><br />
For 3-tap table, first and last columns should contain zeros.<br />
<br />
==LEDs and Display backlight==<br />
The LEDs can be controlled via '''/sys/class/leds/''', and then a file [http://www.gp32x.com/board/index.php?s=&showtopic=45309&view=findpost&p=673593]:<br />
* pandora::sd1<br />
* pandora::sd2<br />
* pandora::charger<br />
* pandora::power<br />
* pandora::bluetooth<br />
* pandora::wifi<br />
* pandora::keypad_bl<br />
Backlight can be controlled via '''/sys/class/backlight/'''.<br />
<br />
==Battery==<br />
There is bq27500 battery monitoring chip onboard, that exports various files at /sys/class/power_supply/bq27500-0/ , for example 'capacity' tells charge percenage left. See [[Data_provided_by_Battery_and_Power_driver]] for more details.<br><br />
There are also similar directories at /sys/class/power_supply/twl4030_* that provide info while charging.<br />
<br />
==Misc==<br />
===Overclocking===<br />
Can be performed by running a helper script<br />
<source lang="bash"><br />
sudo /usr/pandora/scripts/op_cpuspeed.sh X<br />
</source><br />
In case you want to do it from another program or non-interactively, you can use system() function (or similar) with:<br />
<source lang="bash"><br />
sudo -n /usr/pandora/scripts/op_cpuspeed.sh -n X<br />
</source><br />
* Note: you are advised not to change the clock explicitly from a program because optimal clock may differ on different pandora revisions, or somebody might want to run at different clock speed to save battery, CPU life, etc. . Let the user decide about the clock before running the program and set it using the system tools.<br />
* Note: '-n' script argument is not available on pre-SuperZaxxon Final firmwares.<br />
<br />
[[Category:Development]]<br />
[[Category:Kernel]]<br />
[[Category:Hardware]]</div>Lollahttps://pandorawiki.org/index.php?title=Floating_Point_Optimization&diff=28099Floating Point Optimization2013-10-09T22:16:43Z<p>Lolla: </p>
<hr />
<div>== Introduction ==<br />
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.<br />
<br />
'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".<br />
<br />
== Compiler Support ==<br />
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:<br />
* CSL 2007q3: Working NEON, Softfp Support<br />
* CSL 2008q3: Broken NEON!<br />
* CSL 2009q1: Working NEON, Hardfp + Softfp Support<br />
<br />
Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature. <br />
<br />
In order to instruct the compiler to produce NEON or VFP code you should use the following compile flags: <pre>-mfpu=neon or -mfpu=vfp</pre><br />
Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags. <br />
<br />
Therefore i recommend the following flags:<br />
<pre>-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant</pre><br />
where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.<br />
<br />
== VFP-Lite RunFast ==<br />
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.<br />
<br />
In order for VFP instructions to execute in the NFP the following constraints must be met:<br />
* RunFast mode must be enabled<br />
* Must be single precision floating point operands<br />
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)<br />
<br />
Runfast mode is enabled when the following conditions are present:<br />
* Subnormal numbers are being flushed to zero <br />
* Default NaN mode is active<br />
* No floating point exceptions are enabled<br />
<br />
I'm not sure if Runfast mode will be enabled by default in the Angstrom distribution packaged with the Pandora. If it isn't you can use the following C code to enforce it:<br />
<br />
<source lang="c"><br />
void enable_runfast()<br />
{<br />
static const unsigned int x = 0x04086060;<br />
static const unsigned int y = 0x03000000;<br />
int r;<br />
asm volatile (<br />
"fmrx %0, fpscr \n\t" //r0 = FPSCR<br />
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060<br />
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000<br />
"fmxr fpscr, %0 \n\t" //FPSCR = r0<br />
: "=r"(r)<br />
: "r"(x), "r"(y)<br />
);<br />
}</source><br />
<br />
The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.<br />
<br />
== Single Precision Floating Point ==<br />
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require slower double precision instructions and cannot be executed on the NEON. eg<br />
<br />
<source lang="c"><br />
float foo(float x)<br />
{ <br />
return (2.123 * x); <br />
}</source><br />
<br />
might end up the same as:<br />
<br />
<source lang="c"><br />
float foo(float x)<br />
{<br />
double dx = (double) x;<br />
double dy = (double) 2.123; <br />
double dr = dx * dy;<br />
float r = (float) dr;<br />
return r;<br />
}</source><br />
<br />
You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f<br />
<br />
Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt, etc). By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions as well, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().<br />
<br />
== NFP / VFP to ARM Transfers ==<br />
Probably the biggest bottleneck in the architecture is that in order to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC (except the CSL 2009q1 release) supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.<br />
<br />
Another source of NFP / VFP to ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but in order to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie<br />
<source lang="c">if (x < 0) {x += 1.1244;}</source><br />
Is the same as:<br />
<source lang="c">x = x + (x < 0) * 1.1244</source><br />
However you might want to keep a close eye on what the compiler actually produces with the above code. <br />
<br />
One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie<br />
<source lang="c">void foo(float *x, float *r)<br />
{<br />
*r = 123 + *x;<br />
}<br />
<br />
void bar(float *x, float *r)<br />
{<br />
*r = 546 + *x;<br />
}<br />
<br />
void main()<br />
{<br />
float x = 10;<br />
float y, z;<br />
foo(&x, &y)<br />
<br />
//do ~20 cycles of ARM work<br />
<br />
bar(&y, &z);<br />
<br />
}</source><br />
<br />
The last common source of transfers is when you cast a floating point value as an integer, by default all integer work will be done in the ARM pipeline and hence a transfer operation occurs. This is particularly problematic for complex algorithms that rely on bitwise or rounding operations on floating point numbers, ie almost all the functions in cmath depend on range reduction (rounding). A smart compiler would recognize that they can almost always be done in the NEON's integer pipeline.<br />
<br />
== NEON SIMD ==<br />
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.<br />
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly. <br />
<br />
== Summary ==<br />
It's often said amongst software developers that you 'may as well not bother trying to outperform a compiler', whilst there is a grain of truth in this where X86 is concerned, this is definitely not the case with Floating point on the ARM Cortex A8. In fact it is almost the opposite, you can almost always make significant gains via targeting the NEON. Therefore, In order to achieve the best floating point performance on the Pandora (or ARM Cortex A8 device):<br />
* Use the CodeSourcery 2007q3 or 2009q1 releases and these flags<br />
<pre> -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant</pre><br />
* Only use single precision floating point<br />
* Use NEON intrinsics / ASM when ever you find a bottlenecking FP function. You can do better than the compiler.<br />
* Minimize Conditional Branches<br />
* Enable RunFast mode<br />
<br />
For softfp:<br />
* Inline floating point code (unless its very large)<br />
* Pass FP arguments via pointers instead of by value and do integer work in between function calls.<br />
<br />
[[Category:Development]]<br />
[[Category:Chipset]]</div>Lollahttps://pandorawiki.org/index.php?title=Floating_Point_Optimization&diff=28098Floating Point Optimization2013-10-09T22:12:25Z<p>Lolla: </p>
<hr />
<div>== Introduction ==<br />
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.<br />
<br />
'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".<br />
<br />
== Compiler Support ==<br />
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:<br />
* CSL 2007q3: Working NEON, Softfp Support<br />
* CSL 2008q3: Broken NEON!<br />
* CSL 2009q1: Working NEON, Hardfp + Softfp Support<br />
<br />
Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature. <br />
<br />
In order to instruct the compiler to produce NEON or VFP code you should use the following compile flags: <pre>-mfpu=neon or -mfpu=vfp</pre><br />
Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags. <br />
<br />
Therefore i recommend the following flags:<br />
<pre>-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant</pre><br />
where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.<br />
<br />
== VFP-Lite RunFast ==<br />
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.<br />
<br />
In order for VFP instructions to execute in the NFP the following constraints must be met:<br />
* RunFast mode must be enabled<br />
* Must be single precision floating point operands<br />
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)<br />
<br />
Runfast mode is enabled when the following conditions are present:<br />
* Subnormal numbers are being flushed to zero <br />
* Default NaN mode is active<br />
* No floating point exceptions are enabled<br />
<br />
I'm not sure if Runfast mode will be enabled by default in the Angstrom distribution packaged with the Pandora. If it isn't you can use the following C code to enforce it:<br />
<br />
<source lang="c"><br />
void enable_runfast()<br />
{<br />
static const unsigned int x = 0x04086060;<br />
static const unsigned int y = 0x03000000;<br />
int r;<br />
asm volatile (<br />
"fmrx %0, fpscr \n\t" //r0 = FPSCR<br />
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060<br />
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000<br />
"fmxr fpscr, %0 \n\t" //FPSCR = r0<br />
: "=r"(r)<br />
: "r"(x), "r"(y)<br />
);<br />
}</source><br />
<br />
The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.<br />
<br />
== Single Precision Floating Point ==<br />
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require slower double precision instructions and cannot be executed on the NEON. eg<br />
<br />
<source lang="c"><br />
float foo(float x)<br />
{ <br />
return (2.123 * x); <br />
}</source><br />
<br />
might end up the same as:<br />
<br />
<source lang="c"><br />
float foo(float x)<br />
{<br />
double dx = (double) x;<br />
double dy = (double) 2.123; <br />
double dr = dx * dy;<br />
float r = (float) dr;<br />
return r;<br />
}</source><br />
<br />
You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f<br />
<br />
Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt, etc). By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions as well, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().<br />
<br />
== NFP / VFP to ARM Transfers ==<br />
Probably the biggest bottleneck in the architecture is that in order to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC (except the CSL 2009q1 release) supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.<br />
<br />
Another source of NFP / VFP to ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but in order to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie<br />
<source lang="c">if (x < 0) {x += 1.1244;}</source><br />
Is the same as:<br />
<source lang="c">x = x + (x < 0) * 1.1244</source><br />
However you might want to keep a close eye on what the compiler actually produces with the above code. <br />
<br />
One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie<br />
<source lang="c">void foo(float *x, float *r)<br />
{<br />
*r = 123 + *x;<br />
}<br />
<br />
void bar(float *x, float *r)<br />
{<br />
*r = 546 + *x;<br />
}<br />
<br />
void main()<br />
{<br />
float x = 10;<br />
float y, z;<br />
foo(&x, &y)<br />
<br />
//do ~20 cycles of ARM work<br />
<br />
bar(&y, &z);<br />
<br />
}</source><br />
<br />
The last common source of transfers is when you cast a floating point value as an integer, by default all integer work will be done in the ARM pipeline and hence a transfer operation occurs. This is particularly problematic for complex algorithms that rely on bitwise or rounding operations on floating point numbers, ie almost all the functions in cmath depend on range reduction (rounding). A smart compiler would recognize that they can almost always be done in the NEON's integer pipeline.<br />
<br />
== NEON SIMD ==<br />
The [[NEON]] unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.<br />
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly. <br />
<br />
== Summary ==<br />
It's often said amongst software developers that you 'may as well not bother trying to outperform a compiler', whilst there is a grain of truth in this where X86 is concerned, this is definitely not the case with Floating point on the ARM Cortex A8. In fact it is almost the opposite, you can almost always make significant gains via targeting the [[NEON]]. Therefore, In order to achieve the best floating point performance on the Pandora (or ARM Cortex A8 device):<br />
* Use the CodeSourcery 2007q3 or 2009q1 releases and these flags<br />
<pre> -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant</pre><br />
* Only use single precision floating point<br />
* Use NEON intrinsics / ASM when ever you find a bottlenecking FP function. You can do better than the compiler.<br />
* Minimize Conditional Branches<br />
* Enable RunFast mode<br />
<br />
For softfp:<br />
* Inline floating point code (unless its very large)<br />
* Pass FP arguments via pointers instead of by value and do integer work in between function calls.<br />
<br />
[[Category:Development]]<br />
[[Category:Chipset]]</div>Lollahttps://pandorawiki.org/index.php?title=Floating_Point_Optimization&diff=28096Floating Point Optimization2013-10-09T21:59:04Z<p>Lolla: </p>
<hr />
<div>== Introduction ==<br />
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.<br />
<br />
'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".<br />
<br />
== Compiler Support ==<br />
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery [[toolchain]] has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:<br />
* CSL 2007q3: Working NEON, Softfp Support<br />
* CSL 2008q3: Broken NEON!<br />
* CSL 2009q1: Working NEON, Hardfp + Softfp Support<br />
<br />
Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature. <br />
<br />
In order to instruct the compiler to produce NEON or VFP code you should use the following compile flags: <pre>-mfpu=neon or -mfpu=vfp</pre><br />
Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags. <br />
<br />
Therefore i recommend the following flags:<br />
<pre>-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant</pre><br />
where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.<br />
<br />
== VFP-Lite RunFast ==<br />
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.<br />
<br />
In order for VFP instructions to execute in the NFP the following constraints must be met:<br />
* RunFast mode must be enabled<br />
* Must be single precision floating point operands<br />
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)<br />
<br />
Runfast mode is enabled when the following conditions are present:<br />
* Subnormal numbers are being flushed to zero <br />
* Default NaN mode is active<br />
* No floating point exceptions are enabled<br />
<br />
I'm not sure if Runfast mode will be enabled by default in the Angstrom distribution packaged with the Pandora. If it isn't you can use the following C code to enforce it:<br />
<br />
<source lang="c"><br />
void enable_runfast()<br />
{<br />
static const unsigned int x = 0x04086060;<br />
static const unsigned int y = 0x03000000;<br />
int r;<br />
asm volatile (<br />
"fmrx %0, fpscr \n\t" //r0 = FPSCR<br />
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060<br />
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000<br />
"fmxr fpscr, %0 \n\t" //FPSCR = r0<br />
: "=r"(r)<br />
: "r"(x), "r"(y)<br />
);<br />
}</source><br />
<br />
The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.<br />
<br />
== Single Precision Floating Point ==<br />
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require slower double precision instructions and cannot be executed on the NEON. eg<br />
<br />
<source lang="c"><br />
float foo(float x)<br />
{ <br />
return (2.123 * x); <br />
}</source><br />
<br />
might end up the same as:<br />
<br />
<source lang="c"><br />
float foo(float x)<br />
{<br />
double dx = (double) x;<br />
double dy = (double) 2.123; <br />
double dr = dx * dy;<br />
float r = (float) dr;<br />
return r;<br />
}</source><br />
<br />
You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f<br />
<br />
Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt, etc). By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions as well, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().<br />
<br />
== NFP / VFP to ARM Transfers ==<br />
Probably the biggest bottleneck in the architecture is that in order to transfer a number from the [[VFP]] / NFP registers onto the ARM you must stall both the [[ARM]] and [[NFP]] / [[VFP]] for >20 cycles. This is particularly troublesome because this is how GCC (except the CSL 2009q1 release) supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.<br />
<br />
Another source of [[NFP]] / [[VFP]] to [[ARM]] transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but in order to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie<br />
<source lang="c">if (x < 0) {x += 1.1244;}</source><br />
Is the same as:<br />
<source lang="c">x = x + (x < 0) * 1.1244</source><br />
However you might want to keep a close eye on what the compiler actually produces with the above code. <br />
<br />
One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie<br />
<source lang="c">void foo(float *x, float *r)<br />
{<br />
*r = 123 + *x;<br />
}<br />
<br />
void bar(float *x, float *r)<br />
{<br />
*r = 546 + *x;<br />
}<br />
<br />
void main()<br />
{<br />
float x = 10;<br />
float y, z;<br />
foo(&x, &y)<br />
<br />
//do ~20 cycles of ARM work<br />
<br />
bar(&y, &z);<br />
<br />
}</source><br />
<br />
The last common source of transfers is when you cast a floating point value as an integer, by default all integer work will be done in the ARM pipeline and hence a transfer operation occurs. This is particularly problematic for complex algorithms that rely on bitwise or rounding operations on floating point numbers, ie almost all the functions in cmath depend on range reduction (rounding). A smart compiler would recognize that they can almost always be done in the NEON's integer pipeline.<br />
<br />
== NEON SIMD ==<br />
The [[NEON]] unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.<br />
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly. <br />
<br />
== Summary ==<br />
It's often said amongst software developers that you 'may as well not bother trying to outperform a compiler', whilst there is a grain of truth in this where X86 is concerned, this is definitely not the case with Floating point on the ARM Cortex A8. In fact it is almost the opposite, you can almost always make significant gains via targeting the [[NEON]]. Therefore, In order to achieve the best floating point performance on the Pandora (or ARM Cortex A8 device):<br />
* Use the CodeSourcery 2007q3 or 2009q1 releases and these flags<br />
<pre> -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant</pre><br />
* Only use single precision floating point<br />
* Use NEON intrinsics / ASM when ever you find a bottlenecking FP function. You can do better than the compiler.<br />
* Minimize Conditional Branches<br />
* Enable RunFast mode<br />
<br />
For softfp:<br />
* Inline floating point code (unless its very large)<br />
* Pass FP arguments via pointers instead of by value and do integer work in between function calls.<br />
<br />
[[Category:Development]]<br />
[[Category:Chipset]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27715Main Page2013-09-13T23:45:04Z<p>Lolla: </p>
<hr />
<div>{| border="0" cellpadding="0"<br />
! scope="col" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]]<br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]]<br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]]<br />
|-<br />
| •[[NAND]] || •[[Swap]]<br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]] •[[Status]]<br />
|-<br />
|-<br />
| •[[Debian On SD]] •[[Android]]• || [[RISC OS]] •[[Soleil]] || • [[Slackware]]<br />
|-<br />
| •[[Games]] •[[Unreleased]] || •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]] || •[[Greyout]]<br />
|-<br />
| •[[NetKeen]] || •[[Pencil]] || •[[NoteCase Pro]]<br />
|-<br />
! scope="col" | •[[Emulators|<span style="color:green;">EMULATORS</span>]]<br />
|-<br />
| •[[Legal Emulation Resources]] || •[[Emulator List]]<br />
|-<br />
| •[[QEMU]] || •[[QEMU Premade Images]] || •[[QEMU Compatibility]]<br />
|-<br />
| •[[DOSBox]] || •[[compat list]]<br />
|-<br />
| •[[PCSX-ReARMed]] || •[[Creating images of PSX games using Linux]]<br />
|-<br />
| •[[UAE4ALL]]<br />
|-<br />
| •[[MEME4ALL]] || •[[MAME]] || •[[PanMAME]]<br />
|-<br />
| •[[Mupen64plus dynamic recompiler]]<br />
|-<br />
| •[[PicoDrive]]<br />
|-<br />
| •[[SNES9X4P]]<br />
|-<br />
| •[[DraStic Compatibility List]] || •[[compat list 1.x]]<br />
|-<br />
| •[[Compo4All]] || •[[Compo4AllSDK]]<br />
|-<br />
| •[[ResidualVM]] || •[[ScummVM]]<br />
|-<br />
| •[[Emul. ARM sys on win]]<br />
|-<br />
! scope="col" | •[[Gui|<span style="color:green;">GUI</span>]]<br />
|-<br />
| •[[OpenBox]] <br />
|-<br />
| •[[Minimenu]] || •[[Configuration]]<br />
|-<br />
| •[[Screenshot]] || •[[Wallpaper cronjob]]<br />
|-<br />
! scope="col" | •[[development|<span style="color:green;">DEVELOPMENT</span>]]<br />
|-<br />
| •[[Development tutorials]] || •[[Development Tools]]<br />
|-<br />
| •[[SGX drivers]] || •[[SDL]] || •[[SDL Controls]]<br />
|-<br />
| •[[Floating Point Optimization]] || •[[Assembly Optimization]]<br />
|-<br />
| •[[Porting to GLES from GL]] || •[[Porting guide]]<br />
|-<br />
| •[[GLES]] || •[[window]]<br />
|-<br />
| •[[GLESGAE]] || •[[GLBasic tutorial]]<br />
|-<br />
| •[[cross-compiler]] || •[[Compile on the Pandora]]<br />
|- <br />
| [[Client repo API]] || [[Repo delta transfers]]<br />
|-<br />
| •[[PND repo spec]] || •[[PND nub modes]]<br />
|-<br />
| •[[Introduction to PNDs]] || •[[PND:FAQ]]<br />
|-<br />
| •[[Make and run simple PND]] || •[[Mounting a PND]]<br />
|-<br />
| •[[Libpnd hub]] || •[[PND management workflow]]<br />
|-<br />
| •[[PXML specification]] || •[[PXML archetype]]<br />
|-<br />
| •[[PND Cookbook]] || •[[New PND format]]<br />
|-<br />
! scope="col" | •[[Team|<span style="color:green;">TEAM</span>]]<br />
|-<br />
| •[[Community Links]]<br />
|-<br />
| •[[IRC]] || •[[Wiki TODO]] || •[[Donations]] <br />
|-<br />
| •[[Multisite username check]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27714Main Page2013-09-13T23:44:41Z<p>Lolla: </p>
<hr />
<div>{| border="0" cellpadding="0"<br />
! scope="col" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]]<br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]]<br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]]<br />
|-<br />
| •[[NAND]] || •[[Swap]]<br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
|-<br />
|-<br />
|-<br />
|-<br />
! scope="col" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]] •[[Status]]<br />
|-<br />
|-<br />
| •[[Debian On SD]] •[[Android]]• || [[RISC OS]] •[[Soleil]] || • [[Slackware]]<br />
|-<br />
| •[[Games]] •[[Unreleased]] || •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]] || •[[Greyout]]<br />
|-<br />
| •[[NetKeen]] || •[[Pencil]] || •[[NoteCase Pro]]<br />
|-<br />
! scope="col" | •[[Emulators|<span style="color:green;">EMULATORS</span>]]<br />
|-<br />
| •[[Legal Emulation Resources]] || •[[Emulator List]]<br />
|-<br />
| •[[QEMU]] || •[[QEMU Premade Images]] || •[[QEMU Compatibility]]<br />
|-<br />
| •[[DOSBox]] || •[[compat list]]<br />
|-<br />
| •[[PCSX-ReARMed]] || •[[Creating images of PSX games using Linux]]<br />
|-<br />
| •[[UAE4ALL]]<br />
|-<br />
| •[[MEME4ALL]] || •[[MAME]] || •[[PanMAME]]<br />
|-<br />
| •[[Mupen64plus dynamic recompiler]]<br />
|-<br />
| •[[PicoDrive]]<br />
|-<br />
| •[[SNES9X4P]]<br />
|-<br />
| •[[DraStic Compatibility List]] || •[[compat list 1.x]]<br />
|-<br />
| •[[Compo4All]] || •[[Compo4AllSDK]]<br />
|-<br />
| •[[ResidualVM]] || •[[ScummVM]]<br />
|-<br />
| •[[Emul. ARM sys on win]]<br />
|-<br />
! scope="col" | •[[Gui|<span style="color:green;">GUI</span>]]<br />
|-<br />
| •[[OpenBox]] <br />
|-<br />
| •[[Minimenu]] || •[[Configuration]]<br />
|-<br />
| •[[Screenshot]] || •[[Wallpaper cronjob]]<br />
|-<br />
! scope="col" | •[[development|<span style="color:green;">DEVELOPMENT</span>]]<br />
|-<br />
| •[[Development tutorials]] || •[[Development Tools]]<br />
|-<br />
| •[[SGX drivers]] || •[[SDL]] || •[[SDL Controls]]<br />
|-<br />
| •[[Floating Point Optimization]] || •[[Assembly Optimization]]<br />
|-<br />
| •[[Porting to GLES from GL]] || •[[Porting guide]]<br />
|-<br />
| •[[GLES]] || •[[window]]<br />
|-<br />
| •[[GLESGAE]] || •[[GLBasic tutorial]]<br />
|-<br />
| •[[cross-compiler]] || •[[Compile on the Pandora]]<br />
|- <br />
| [[Client repo API]] || [[Repo delta transfers]]<br />
|-<br />
| •[[PND repo spec]] || •[[PND nub modes]]<br />
|-<br />
| •[[Introduction to PNDs]] || •[[PND:FAQ]]<br />
|-<br />
| •[[Make and run simple PND]] || •[[Mounting a PND]]<br />
|-<br />
| •[[Libpnd hub]] || •[[PND management workflow]]<br />
|-<br />
| •[[PXML specification]] || •[[PXML archetype]]<br />
|-<br />
| •[[PND Cookbook]] || •[[New PND format]]<br />
|-<br />
! scope="col" | •[[Team|<span style="color:green;">TEAM</span>]]<br />
|-<br />
| •[[Community Links]]<br />
|-<br />
| •[[IRC]] || •[[Wiki TODO]] || •[[Donations]] <br />
|-<br />
| •[[Multisite username check]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27713Main Page2013-09-13T23:41:29Z<p>Lolla: </p>
<hr />
<div>{| border="0" cellpadding="0"<br />
! scope="col" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]]<br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]]<br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]]<br />
|-<br />
| •[[NAND]] || •[[Swap]]<br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]] •[[Status]]<br />
|-<br />
|-<br />
| •[[Debian On SD]] •[[Android]]• || [[RISC OS]] •[[Soleil]] || • [[Slackware]]<br />
|-<br />
| •[[Games]] •[[Unreleased]] || •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]] || •[[Greyout]]<br />
|-<br />
| •[[NetKeen]] || •[[Pencil]] || •[[NoteCase Pro]]<br />
|-<br />
! scope="col" | •[[Emulators|<span style="color:green;">EMULATORS</span>]]<br />
|-<br />
| •[[Legal Emulation Resources]] || •[[Emulator List]]<br />
|-<br />
| •[[QEMU]] || •[[QEMU Premade Images]] || •[[QEMU Compatibility]]<br />
|-<br />
| •[[DOSBox]] || •[[compat list]]<br />
|-<br />
| •[[PCSX-ReARMed]] || •[[Creating images of PSX games using Linux]]<br />
|-<br />
| •[[UAE4ALL]]<br />
|-<br />
| •[[MEME4ALL]] || •[[MAME]] || •[[PanMAME]]<br />
|-<br />
| •[[Mupen64plus dynamic recompiler]]<br />
|-<br />
| •[[PicoDrive]]<br />
|-<br />
| •[[SNES9X4P]]<br />
|-<br />
| •[[DraStic Compatibility List]] || •[[compat list 1.x]]<br />
|-<br />
| •[[Compo4All]] || •[[Compo4AllSDK]]<br />
|-<br />
| •[[ResidualVM]] || •[[ScummVM]]<br />
|-<br />
| •[[Emul. ARM sys on win]]<br />
|-<br />
! scope="col" | •[[Gui|<span style="color:green;">GUI</span>]]<br />
|-<br />
| •[[OpenBox]] <br />
|-<br />
| •[[Minimenu]] || •[[Configuration]]<br />
|-<br />
| •[[Screenshot]] || •[[Wallpaper cronjob]]<br />
|-<br />
! scope="col" | •[[development|<span style="color:green;">DEVELOPMENT</span>]]<br />
|-<br />
| •[[Development tutorials]] || •[[Development Tools]]<br />
|-<br />
| •[[SGX drivers]] || •[[SDL]] || •[[SDL Controls]]<br />
|-<br />
| •[[Floating Point Optimization]] || •[[Assembly Optimization]]<br />
|-<br />
| •[[Porting to GLES from GL]] || •[[Porting guide]]<br />
|-<br />
| •[[GLES]] || •[[window]]<br />
|-<br />
| •[[GLESGAE]] || •[[GLBasic tutorial]]<br />
|-<br />
| •[[cross-compiler]] || •[[Compile on the Pandora]]<br />
|- <br />
| [[Client repo API]] || [[Repo delta transfers]]<br />
|-<br />
| •[[PND repo spec]] || •[[PND nub modes]]<br />
|-<br />
| •[[Introduction to PNDs]] || •[[PND:FAQ]]<br />
|-<br />
| •[[Make and run simple PND]] || •[[Mounting a PND]]<br />
|-<br />
| •[[Libpnd hub]] || •[[PND management workflow]]<br />
|-<br />
| •[[PXML specification]] || •[[PXML archetype]]<br />
|-<br />
| •[[PND Cookbook]] || •[[New PND format]]<br />
|-<br />
! scope="col" | •[[Team|<span style="color:green;">TEAM</span>]]<br />
|-<br />
| •[[Community Links]]<br />
|-<br />
| •[[IRC]] || •[[Wiki TODO]] || •[[Donations]] <br />
|-<br />
| •[[Multisite username check]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27712Main Page2013-09-13T23:40:29Z<p>Lolla: </p>
<hr />
<div>{| border="0" cellpadding="0"<br />
! scope="col" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]]<br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]]<br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]]<br />
|-<br />
| •[[NAND]] || •[[Swap]]<br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]] •[[Status]]<br />
|-<br />
|-<br />
| •[[Debian On SD]] •[[Android]]• || [[RISC OS]] •[[Soleil]] || • [[Slackware]]<br />
|-<br />
| •[[Games]] •[[Unreleased]] || •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]] || •[[Greyout]]<br />
|-<br />
| •[[NetKeen]] || •[[Pencil]] || •[[NoteCase Pro]]<br />
|-<br />
! scope="col" | •[[Emulators|<span style="color:green;">EMULATORS</span>]]<br />
|-<br />
| •[[Legal Emulation Resources]] || •[[Emulator List]]<br />
|-<br />
| •[[QEMU]] || •[[QEMU Premade Images]] || •[[QEMU Compatibility]]<br />
|-<br />
| •[[DOSBox]] || •[[compat list]]<br />
|-<br />
| •[[PCSX-ReARMed]] || •[[Creating images of PSX games using Linux]]<br />
|-<br />
| •[[UAE4ALL]]<br />
|-<br />
| •[[MEME4ALL]] || •[[MAME]] || •[[PanMAME]]<br />
|-<br />
| •[[Mupen64plus dynamic recompiler]]<br />
|-<br />
| •[[PicoDrive]]<br />
|-<br />
| •[[SNES9X4P]]<br />
|-<br />
| •[[DraStic Compatibility List]] || •[[compat list 1.x]]<br />
|-<br />
| •[[Compo4All]] || •[[Compo4AllSDK]]<br />
|-<br />
| •[[ResidualVM]] || •[[ScummVM]]<br />
|-<br />
| •[[Emul. ARM sys on win]]<br />
|-<br />
! scope="col" | •[[Gui|<span style="color:green;">GUI</span>]]<br />
|-<br />
| •[[OpenBox]] <br />
|-<br />
| •[[Minimenu]] || •[[Configuration]]<br />
|-<br />
| •[[Screenshot]] || •[[Wallpaper cronjob]]<br />
|-<br />
|-<br />
! scope="col" | •[[Getting started with pandora development|<span style="color:green;">GETTING STARTED WITH PANDORA DEVELOPMENT</span>]]<br />
|-<br />
| •[[Development tutorials]] || •[[Development Tools]]<br />
|-<br />
| •[[SGX drivers]] || •[[SDL]] || •[[SDL Controls]]<br />
|-<br />
| •[[Floating Point Optimization]] || •[[Assembly Optimization]]<br />
|-<br />
| •[[Porting to GLES from GL]] || •[[Porting guide]]<br />
|-<br />
| •[[GLES]] || •[[window]]<br />
|-<br />
| •[[GLESGAE]] || •[[GLBasic tutorial]]<br />
|-<br />
| •[[cross-compiler]] || •[[Compile on the Pandora]]<br />
|- <br />
| [[Client repo API]] || [[Repo delta transfers]]<br />
|-<br />
| •[[PND repo spec]] || •[[PND nub modes]]<br />
|-<br />
| •[[Introduction to PNDs]] || •[[PND:FAQ]]<br />
|-<br />
| •[[Make and run simple PND]] || •[[Mounting a PND]]<br />
|-<br />
| •[[Libpnd hub]] || •[[PND management workflow]]<br />
|-<br />
| •[[PXML specification]] || •[[PXML archetype]]<br />
|-<br />
| •[[PND Cookbook]] || •[[New PND format]]<br />
|-<br />
! scope="col" | •[[Team|<span style="color:green;">TEAM</span>]]<br />
|-<br />
| •[[Community Links]]<br />
|-<br />
| •[[IRC]] || •[[Wiki TODO]] || •[[Donations]] <br />
|-<br />
| •[[Multisite username check]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27711Main Page2013-09-13T23:39:37Z<p>Lolla: </p>
<hr />
<div>{| border="0" cellpadding="0"<br />
! scope="col" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]]<br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]]<br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]]<br />
|-<br />
| •[[NAND]] || •[[Swap]]<br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]] •[[Status]]<br />
|-<br />
|-<br />
| •[[Debian On SD]] •[[Android]]• || [[RISC OS]] •[[Soleil]] || • [[Slackware]]<br />
|-<br />
| •[[Games]] •[[Unreleased]] || •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]] || •[[Greyout]]<br />
|-<br />
| •[[NetKeen]] || •[[Pencil]] || •[[NoteCase Pro]]<br />
|-<br />
! scope="col" | •[[Emulators|<span style="color:green;">EMULATORS</span>]]<br />
|-<br />
| •[[Legal Emulation Resources]] || •[[Emulator List]]<br />
|-<br />
| •[[QEMU]] || •[[QEMU Premade Images]] || •[[QEMU Compatibility]]<br />
|-<br />
| •[[DOSBox]] || •[[compat list]]<br />
|-<br />
| •[[PCSX-ReARMed]] || •[[Creating images of PSX games using Linux]]<br />
|-<br />
| •[[UAE4ALL]]<br />
|-<br />
| •[[MEME4ALL]] || •[[MAME]] || •[[PanMAME]]<br />
|-<br />
| •[[Mupen64plus dynamic recompiler]]<br />
|-<br />
| •[[PicoDrive]]<br />
|-<br />
| •[[SNES9X4P]]<br />
|-<br />
| •[[DraStic Compatibility List]] || •[[compat list 1.x]]<br />
|-<br />
| •[[Compo4All]] || •[[Compo4AllSDK]]<br />
|-<br />
| •[[ResidualVM]] || •[[ScummVM]]<br />
|-<br />
| •[[Emul. ARM sys on win]]<br />
|-<br />
! scope="col" | •[[Gui|<span style="color:green;">GUI</span>]]<br />
|-<br />
| •[[OpenBox]] <br />
|-<br />
| •[[Minimenu]] || •[[Configuration]]<br />
|-<br />
| •[[Screenshot]] || •[[Wallpaper cronjob]]<br />
|-<br />
! scope="col" | •[[Getting started with pandora development|<span style="color:green;">GETTING STARTED WITH PANDORA DEVELOPMENT</span>]]<br />
|-<br />
| •[[Development tutorials]] || •[[Development Tools]]<br />
|-<br />
| •[[SGX drivers]] || •[[SDL]] || •[[SDL Controls]]<br />
|-<br />
| •[[Floating Point Optimization]] || •[[Assembly Optimization]]<br />
|-<br />
| •[[Porting to GLES from GL]] || •[[Porting guide]]<br />
|-<br />
| •[[GLES]] || •[[window]]<br />
|-<br />
| •[[GLESGAE]] || •[[GLBasic tutorial]]<br />
|-<br />
| •[[cross-compiler]] || •[[Compile on the Pandora]]<br />
|- <br />
| [[Client repo API]] || [[Repo delta transfers]]<br />
|-<br />
| •[[PND repo spec]] || •[[PND nub modes]]<br />
|-<br />
| •[[Introduction to PNDs]] || •[[PND:FAQ]]<br />
|-<br />
| •[[Make and run simple PND]] || •[[Mounting a PND]]<br />
|-<br />
| •[[Libpnd hub]] || •[[PND management workflow]]<br />
|-<br />
| •[[PXML specification]] || •[[PXML archetype]]<br />
|-<br />
| •[[PND Cookbook]] || •[[New PND format]]<br />
|-<br />
! scope="col" | •[[Team|<span style="color:green;">TEAM</span>]]<br />
|-<br />
| •[[Community Links]]<br />
|-<br />
| •[[IRC]] || •[[Wiki TODO]] || •[[Donations]] <br />
|-<br />
| •[[Multisite username check]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27710Main Page2013-09-13T23:38:28Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]]<br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]]<br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]]<br />
|-<br />
| •[[NAND]] || •[[Swap]]<br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]] •[[Status]]<br />
|-<br />
|-<br />
| •[[Debian On SD]] •[[Android]]• || [[RISC OS]] •[[Soleil]] || • [[Slackware]]<br />
|-<br />
| •[[Games]] •[[Unreleased]] || •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]] || •[[Greyout]]<br />
|-<br />
| •[[NetKeen]] || •[[Pencil]] || •[[NoteCase Pro]]<br />
|-<br />
! scope="col" | •[[Emulators|<span style="color:green;">EMULATORS</span>]]<br />
|-<br />
| •[[Legal Emulation Resources]] || •[[Emulator List]]<br />
|-<br />
| •[[QEMU]] || •[[QEMU Premade Images]] || •[[QEMU Compatibility]]<br />
|-<br />
| •[[DOSBox]] || •[[compat list]]<br />
|-<br />
| •[[PCSX-ReARMed]] || •[[Creating images of PSX games using Linux]]<br />
|-<br />
| •[[UAE4ALL]]<br />
|-<br />
| •[[MEME4ALL]] || •[[MAME]] || •[[PanMAME]]<br />
|-<br />
| •[[Mupen64plus dynamic recompiler]]<br />
|-<br />
| •[[PicoDrive]]<br />
|-<br />
| •[[SNES9X4P]]<br />
|-<br />
| •[[DraStic Compatibility List]] || •[[compat list 1.x]]<br />
|-<br />
| •[[Compo4All]] || •[[Compo4AllSDK]]<br />
|-<br />
| •[[ResidualVM]] || •[[ScummVM]]<br />
|-<br />
| •[[Emul. ARM sys on win]]<br />
|-<br />
! scope="col" | •[[Gui|<span style="color:green;">GUI</span>]]<br />
|-<br />
| •[[OpenBox]] <br />
|-<br />
| •[[Minimenu]] || •[[Configuration]]<br />
|-<br />
| •[[Screenshot]] || •[[Wallpaper cronjob]]<br />
|-<br />
! scope="col" | •[[Getting started with pandora development|<span style="color:green;">GETTING STARTED WITH PANDORA DEVELOPMENT</span>]]<br />
|-<br />
| •[[Development tutorials]] || •[[Development Tools]]<br />
|-<br />
| •[[SGX drivers]] || •[[SDL]] || •[[SDL Controls]]<br />
|-<br />
| •[[Floating Point Optimization]] || •[[Assembly Optimization]]<br />
|-<br />
| •[[Porting to GLES from GL]] || •[[Porting guide]]<br />
|-<br />
| •[[GLES]] || •[[window]]<br />
|-<br />
| •[[GLESGAE]] || •[[GLBasic tutorial]]<br />
|-<br />
| •[[cross-compiler]] || •[[Compile on the Pandora]]<br />
|- <br />
| [[Client repo API]] || [[Repo delta transfers]]<br />
|-<br />
| •[[PND repo spec]] || •[[PND nub modes]]<br />
|-<br />
| •[[Introduction to PNDs]] || •[[PND:FAQ]]<br />
|-<br />
| •[[Make and run simple PND]] || •[[Mounting a PND]]<br />
|-<br />
| •[[Libpnd hub]] || •[[PND management workflow]]<br />
|-<br />
| •[[PXML specification]] || •[[PXML archetype]]<br />
|-<br />
| •[[PND Cookbook]] || •[[New PND format]]<br />
|-<br />
! scope="col" | •[[Team|<span style="color:green;">TEAM</span>]]<br />
|-<br />
| •[[Community Links]]<br />
|-<br />
| •[[IRC]] || •[[Wiki TODO]] || •[[Donations]] <br />
|-<br />
| •[[Multisite username check]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27707Main Page2013-09-13T23:22:56Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]]<br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]]<br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]]<br />
|-<br />
| •[[NAND]] || •[[Swap]]<br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]] •[[Status]]<br />
|-<br />
|-<br />
| •[[Debian On SD]] •[[Android]]• || [[RISC OS]] •[[Soleil]] || • [[Slackware]]<br />
|-<br />
| •[[Games]] •[[Unreleased]] || •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]] || •[[Greyout]]<br />
|-<br />
| •[[NetKeen]] || •[[Pencil]] || •[[NoteCase Pro]]<br />
|-<br />
! scope="col" | •[[Emulators|<span style="color:green;">EMULATORS</span>]]<br />
|-<br />
| •[[Legal Emulation Resources]] || •[[Emulator List]]<br />
|-<br />
| •[[QEMU]] || •[[QEMU Premade Images]] || •[[QEMU Compatibility]]<br />
|-<br />
| •[[DOSBox]] || •[[compat list]]<br />
|-<br />
| •[[PCSX-ReARMed]] || •[[Creating images of PSX games using Linux]]<br />
|-<br />
| •[[UAE4ALL]]<br />
|-<br />
| •[[MEME4ALL]] || •[[MAME]] || •[[PanMAME]]<br />
|-<br />
| •[[Mupen64plus dynamic recompiler]]<br />
|-<br />
| •[[PicoDrive]]<br />
|-<br />
| •[[SNES9X4P]]<br />
|-<br />
| •[[DraStic Compatibility List]] || •[[compat list 1.x]]<br />
|-<br />
| •[[Compo4All]] || •[[Compo4AllSDK]]<br />
|-<br />
| •[[ResidualVM]] || •[[ScummVM]]<br />
|-<br />
| •[[Emul. ARM sys on win]]<br />
|-<br />
! scope="col" | •[[Gui|<span style="color:green;">GUI</span>]]<br />
|-<br />
| •[[OpenBox]] <br />
|-<br />
| •[[Minimenu]] || •[[Configuration]]<br />
|-<br />
| •[[Screenshot]] || •[[Wallpaper cronjob]]<br />
|-<br />
! scope="col" | •[[Getting started with pandora development|<span style="color:green;">GETTING STARTED WITH PANDORA DEVELOPMENT</span>]]<br />
|-<br />
| •[[Development tutorials]] || •[[Development Tools]]<br />
|-<br />
| •[[SGX drivers]] || •[[SDL]] || •[[SDL Controls]]<br />
|-<br />
| •[[Floating Point Optimization]] || •[[Assembly Optimization]]<br />
|-<br />
| •[[Porting to GLES from GL]] || •[[Porting guide]]<br />
|-<br />
| •[[GLES]] || •[[window]]<br />
|-<br />
| •[[GLESGAE]] || •[[GLBasic tutorial]]<br />
|-<br />
| •[[cross-compiler]] || •[[Compile on the Pandora]]<br />
|-<br />
| •[[Client repo API]] || •[[Repo delta transfers]]<br />
|-<br />
| •[[PND repo spec]] || •[[PND nub modes]]<br />
|-<br />
| •[[Introduction to PNDs]] || •[[PND:FAQ]]<br />
|-<br />
| •[[Make and run simple PND]] || •[[Mounting a PND]]<br />
|-<br />
| •[[Libpnd hub]] || •[[PND management workflow]]<br />
|-<br />
| •[[PXML specification]] || •[[PXML archetype]]<br />
|-<br />
| •[[PND Cookbook || •[[New PND format]]<br />
|-</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27706Main Page2013-09-13T23:04:13Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]]<br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]]<br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]]<br />
|-<br />
| •[[NAND]] || •[[Swap]]<br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]] •[[Status]]<br />
|-<br />
|-<br />
| •[[Debian On SD]] •[[Android]]• || [[RISC OS]] •[[Soleil]] || • [[Slackware]]<br />
|-<br />
| •[[Games]] •[[Unreleased]] || •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]] || •[[Greyout]]<br />
|-<br />
| •[[NetKeen]] || •[[Pencil]] || •[[NoteCase Pro]]<br />
|-<br />
! scope="col" | •[[Emulators|<span style="color:green;">EMULATORS</span>]]<br />
|-<br />
| •[[Legal Emulation Resources]] || •[[Emulator List]]<br />
|-<br />
| •[[QEMU]] || •[[QEMU Premade Images]] || •[[QEMU Compatibility]]<br />
|-<br />
| •[[DOSBox]] || •[[compat list]]<br />
|-<br />
| •[[PCSX-ReARMed]] || •[[Creating images of PSX games using Linux]]<br />
|-<br />
| •[[UAE4ALL]]<br />
|-<br />
| •[[MEME4ALL]] || •[[MAME]] || •[[PanMAME]]<br />
|-<br />
| •[[Mupen64plus dynamic recompiler]]<br />
|-<br />
| •[[PicoDrive]]<br />
|-<br />
| •[[SNES9X4P]]<br />
|-<br />
| •[[DraStic Compatibility List]] || •[[compat list 1.x]]<br />
|-<br />
| •[[Compo4All]] || •[[Compo4AllSDK]]<br />
|-<br />
| •[[ResidualVM]] || •[[ScummVM]]<br />
|-<br />
| •[[Emul. ARM sys on win]]<br />
|-<br />
! scope="col" | •[[Gui|<span style="color:green;">GUI</span>]]<br />
|-<br />
| •[[OpenBox]] <br />
|-<br />
| •[[Minimenu]] || •[[Configuration]]<br />
|-<br />
| •[[Screenshot]] || •[[Wallpaper cronjob]]<br />
|-</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27705Main Page2013-09-13T23:03:18Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]]<br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]]<br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]]<br />
|-<br />
| •[[NAND]] || •[[Swap]]<br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]] •[[Status]]<br />
|-<br />
|-<br />
| •[[Debian On SD]] •[[Android]]• || [[RISC OS]] •[[Soleil]] || • [[Slackware]]<br />
|-<br />
| •[[Games]] •[[Unreleased]] || •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]] || •[[Greyout]]<br />
|-<br />
| •[[NetKeen]] || •[[Pencil]] || •[[NoteCase Pro]]<br />
|-<br />
! scope="col" | •[[Emulators|<span style="color:green;">EMULATORS</span>]]<br />
|-<br />
| •[[Legal Emulation Resources]] || •[[Emulator List]]<br />
|-<br />
| •[[QEMU]] || •[[QEMU Premade Images]] || •[[QEMU Compatibility]]<br />
|-<br />
| •[[DOSBox]] || •[[compat list]]<br />
|-<br />
| •[[PCSX-ReARMed]] || •[[Creating images of PSX games using Linux]]<br />
|-<br />
| •[[UAE4ALL]]<br />
|-<br />
| •[[MEME4ALL]] || •[[MAME]] || •[[PanMAME]]<br />
|-<br />
| •[[Mupen64plus dynamic recompiler]]<br />
|-<br />
| •[[PicoDrive]]<br />
|-<br />
| •[[SNES9X4P]]<br />
|-<br />
| •[[DraStic Compatibility List]] || •[[compat list 1.x]]<br />
|-<br />
| •[[Compo4All]] || •[[Compo4AllSDK]]<br />
|-<br />
| •[[ResidualVM]] || •[[ScummVM]]<br />
|-<br />
| •[[Emul. ARM sys on win]]<br />
|-<br />
! scope="col" | •[[Gui|<span style="color:green;">•GUI</span>]]<br />
|-<br />
| •[[OpenBox]] <br />
|-<br />
| •[[Minimenu]] || •[[Configuration]]<br />
|-<br />
| •[[Screenshot]] || •[[Wallpaper cronjob]]<br />
|-</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27702Main Page2013-09-13T22:36:46Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]] •[[Status]]<br />
|-<br />
|-<br />
| •[[Debian On SD]] •[[Android]]• || [[RISC OS]] •[[Soleil]] || • [[Slackware]]<br />
|-<br />
| •[[Games]] •[[Unreleased]] || •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]] || •[[Greyout]]<br />
|-<br />
| •[[NetKeen]] || •[[Pencil]] || •[[NoteCase Pro]]<br />
|-<br />
! scope="col" width="225px" | •[[Emulators|<span style="color:green;">EMULATORS</span>]]<br />
|-<br />
| •[[Legal Emulation Resources]] || •[[Emulator List]]<br />
|-<br />
| •[[QEMU]] || •[[QEMU Premade Images]] || •[[QEMU Compatibility]]<br />
|-<br />
| •[[DOSBox]] || •[[compat list]]<br />
|-<br />
| •[[PCSX-ReARMed]] || •[[Creating images of PSX games using Linux]]<br />
|-<br />
| •[[UAE4ALL]]<br />
|-<br />
| •[[MAME4ALL]] || •[[MAME]] || •[[PanMAME]]<br />
|-<br />
| •[[Mupen64plus dynamic recompiler]]<br />
|-<br />
| •[[PicoDrive]]<br />
|-<br />
| •[[SNES9X4P]]<br />
|-<br />
| •[[DraStic Compatibility List]] || •[[compat list 1.x]]<br />
|-<br />
| •[[Compo4All]] || •[[Compo4AllSDK]]<br />
|-<br />
| •[[ResidualVM]] || •[[ScummVM]]<br />
|-<br />
| •[[Emul. ARM sys on win]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27699Main Page2013-09-13T22:12:43Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]]<br />
|-<br />
•[[Kernel build instructions]]<br />
|-<br />
| •[[Interface]] || •[[Status]]<br />
|-<br />
| •[[Debian On SD]] •[[Android]]<br />
|-<br />
|• [[RISC OS]] || •[[Soleil]] <br />
|-<br />
|• [[Slackware]]<br />
|-<br />
| •[[Games]] || •[[Unreleased]] <br />
|-<br />
| •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]]<br />
|-<br />
| •[[Greyout]] || •[[NetKeen]]<br />
|-<br />
| •[[Pencil]] || •[[NoteCase Pro]]<br />
|-</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27698Main Page2013-09-13T22:08:08Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]]<br />
|-<br />
•[[Kernel build instructions]]<br />
|-<br />
| •[[Interface]] || •[[Status]]<br />
|-<br />
| •[[Debian On SD]] •[[Android]]<br />
|-<br />
|• [[RISC OS]] || •[[Soleil]] <br />
|-<br />
|• [[Slackware]]<br />
|-<br />
| •[[Games]] || •[[Unreleased]] <br />
|-<br />
| •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]]<br />
|-<br />
| •[[Greyout]] || •[[NetKeen]] || •[[Pencil]]<br />
|-<br />
| •[[NoteCase Pro]]<br />
|-</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27697Main Page2013-09-13T22:06:55Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]]<br />
|-<br />
•[[Kernel build instructions]]<br />
|-<br />
| •[[Interface]] || •[[Status]]<br />
|-<br />
| •[[Debian On SD]] •[[Android]]<br />
|-<br />
|• [[RISC OS]] || •[[Soleil]] <br />
|-<br />
|• [[Slackware]]<br />
|-<br />
| •[[Games]] || •[[Unreleased]] <br />
|-<br />
| •[[Pandora Bounties]] || •[[Port Requests]]<br />
|-<br />
| •[[PickleLauncher]] || •[[MogsVsDogs]]<br />
|-<br />
| •[[Greyout]] || •[[NetKeen•Pencil]]<br />
|-<br />
| •[[NoteCase Pro]]<br />
<br />
|-<br />
| •[[Pandora Bounties]] ||<br />
| •[[Greyout]] || •[[NetKeen]] || •[[Pencil•NoteCase Pro</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27696Main Page2013-09-13T21:59:06Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]]<br />
|-<br />
•[[Kernel build instructions]]<br />
|-<br />
| •[[Interface]] || •[[Status]]<br />
|-<br />
| •[[Debian On SD]] •[[Android]]<br />
|-<br />
|• [[RISC OS]] || •[[Soleil]] <br />
|-<br />
|• [[Slackware]]<br />
|-<br />
| •[[Games]] || •[[Unreleased]] || •[[Pandora Bounties]]<br />
|-<br />
| •[[Port Requests]] || •[[PickleLauncher]] || •[[MogsVsDogs]]<br />
|-<br />
| •[[Greyout]]•NetKeen•Pencil•NoteCase Pro</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27695Main Page2013-09-13T21:58:20Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]]<br />
|-<br />
•[[Kernel build instructions]]<br />
|-<br />
| •[[Interface]] || •[[Status]]<br />
|-<br />
| •[[Debian On SD]] •[[Android]]<br />
|-<br />
|• [[RISC OS]] || •[[Soleil]] <br />
|-<br />
|• [[Slackware]]<br />
| •[[Games]] || •[[Unreleased]] || •[[Pandora Bounties]]<br />
|-<br />
| •[[Port Requests]] || •[[PickleLauncher]] || •[[MogsVsDogs]]<br />
|-<br />
| •[[Greyout]]•NetKeen•Pencil•NoteCase Pro</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27694Main Page2013-09-13T21:45:49Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]]<br />
|-<br />
| •[[Status]] || •[[Debian On SD]] || •[[Android]]<br />
|-<br />
| •[[RISC OS]] || •[[Soleil]] || •[[Slackware]]<br />
|-<br />
| •[[Games]] || •[[Unreleased]] || •[[Pandora Bounties]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27693Main Page2013-09-13T21:41:18Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]]<br />
|-<br />
| •[[Status]] || •[[Debian On SD]] || •[[Android]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27692Main Page2013-09-13T21:36:31Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]<br />
|-<br />
| •[[Extend Utils]] || •[[Kernel build instructions]] || •[[Interface]] || •[[Status]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27691Main Page2013-09-13T21:34:15Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
|-<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| •[[Ångström]] || •[[Basic Linux Guide]] || •[[Reporting bugs]]</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27688Main Page2013-09-13T21:30:20Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
! scope="col" width="225px" | •[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27685Main Page2013-09-13T21:23:54Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
! scope="col" width="225px" |<br />
! scope="col" width="225px" | EfSSSect<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband]] || •[[dvb-t]]<br />
<br />
<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| 1 || 2 ||[[File:Pandora_logo_small.png|link=Logo|left|97px|thumb]] 3<br />
|-<br />
| 1 || 2 || 3<br />
|}</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27684Main Page2013-09-13T21:21:24Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
! scope="col" width="225px" |<br />
! scope="col" width="225px" | EfSSSect<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
|-<br />
| •[[Keyboard]] || •[[Nubs]] || •[[Wiimote]]<br />
|-<br />
| •[[Power modes]] || •[[Overclocking]] || •[[Hardware defects]]<br />
|-<br />
| •[[GPS]] || •[[Mobile Broadband•dvb-t]]<br />
<br />
<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| 1 || 2 ||[[File:Pandora_logo_small.png|link=Logo|left|97px|thumb]] 3<br />
|-<br />
| 1 || 2 || 3<br />
|}</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27683Main Page2013-09-13T21:15:58Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
! scope="col" width="225px" |<br />
! scope="col" width="225px" | EfSSSect<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || <br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || <br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || <br />
|-<br />
| •[[NAND]] || •[[Swap]] || <br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| 1 || 2 ||[[File:Pandora_logo_small.png|link=Logo|left|97px|thumb]] 3<br />
|-<br />
| 1 || 2 || 3<br />
|}</div>Lollahttps://pandorawiki.org/index.php?title=Main_Page&diff=27682Main Page2013-09-13T21:14:05Z<p>Lolla: </p>
<hr />
<div>{| border="1" cellpadding="1"<br />
! scope="col" width="225px" | •[[Hardware documentation|<span style="color:green;">HARDWARE DOCUMENTATION</span>]]<br />
! scope="col" width="225px" |<br />
! scope="col" width="225px" | EfSSSect<br />
|-<br />
| •[[Hardware Hacking]] || •[[Configuring ext signals]] || All versions<br />
|-<br />
| •[[USB reference]] || •[[USB compatibility list]] || All versions<br />
|- <br />
| •[[SD compat. list]] || •[[Formatting]] || •[[Backup SD inst.to SD]]<br />
|-<br />
| •[[Display]] || •[[LEDs and backlight]] || All versions<br />
|-<br />
| •[[NAND]] || •[[Swap]] || All versions<br />
|-<br />
| •[[WiFi]] || •[[Wireless from the Terminal]] || •[[Bluetooth]]<br />
|-<br />
| •[[Audio system]] || •[[MIDI]] || •[[Microphone]]<br />
<br />
! scope="col" width="225px" |•[[Software projects|<span style="color:green;">SOFTWARE PROJECTS</span>]]<br />
|-<br />
| 1 || 2 ||[[File:Pandora_logo_small.png|link=Logo|left|97px|thumb]] 3<br />
|-<br />
| 1 || 2 || 3<br />
|}</div>Lolla