August 17, 2017, 08:09:23 pm
News:
Pages: [1]
Print
Author Topic: Rick's crash course in compiling for the OSD under Windows  (Read 6687 times)
heyrick
Global Moderator
Sr. Member
*****
Posts: 340



View Profile WWW
« on: December 12, 2010, 05:51:20 pm »

Rick's crash course in compiling for the OSD under Windows (Windows XP).


** VERSION TWO - this one works Wink **


You can obtain a complete copy of this information, as a text file, from:
http://www.heyrick.co.uk/osd/osd%20compile%20under%20linux.txt



With a shout out to ChadV and greyback.



Précis

This is a (rough) guide to installing an environment capable of building code for the Neuros OSD under Windows XP (but should be the same idea for Vista, 7...); but NOT the 64 bit versions.

This has been done for two reasons. The first is flexibility. Those used to Windows may have difficulty with the Unix way of doing things, and secondly it alleviates having to go through the chaos of trying to bring up a Linux system from scratch, say, on an SD card or the like.

What we are going to do here is cheat. Epically. We will have both Windows and Ubuntu running together, at the SAME time.

Don't get me wrong, it is SLOW on older hardware. However I have this running right now as I type this on an eeePC (Atom N270, 1.6GHz with 1Gb RAM) and it is functional. Certainly it is a LOT better than swapping operating systems here and there!


IMPORTANT: Schedule a few HOURS to get the base Linux system set up.
           Then plan to leave your machine running overnight to unpack the sources.
           Then schedule more time (at LEAST two hours) the following day
           to begin the build process. Plus leaving your box ALL DAY or
           OVERNIGHT (yes, again) in order to get Qt and the main apps built.

           This is based upon an eeePC 901XP with 1.6GHz Atom CPU. Adjust as
           appropriate for your hardware.



Step 1 - get the sources

Download the source bundle from:
  http://files.neurostechnology.com/neuros-osd/neuros-osd_source_22-10-2010.tar.bz2

It is a compressed TAR archive. Don't try to unpack it, just pop it somewhere convenient such as, say, a Flash drive. It is 328Mb, so you might find it better to use a download manager. I, personally, recommend FreeDownloadManager which may be obtained from:
  http://www.freedownloadmanager.org/
Unless you need Torrent support, upload manager, and video conversions, you can install the "Lite" version. For general 'happy' downloads, the Lite works just fine.



Step 2 - get Ubuntu

But not a normal one!
  http://sourceforge.net/projects/portableubuntu/

This is a special "CoLinux" version of Ubuntu 9.10 that runs in, and co-exists with, Windows. Pretty awesomely, too.

Ignore the "download latest version" button. It's set to something else (duh!). You'll want to get the download directly from here:
  http://sourceforge.net/projects/portableubuntu/files/portableubuntu/TRES/

Click on the entry "Portable_Ubuntu_TRES.exe". It is a 587Mb file. So, yeah, download manager again... Wink



Step 3 - install Ubuntu

Virus-scan the .EXE just to be safe. Then run it. It is a self-decompressing 7zip archive that unpacks a rather large amount of stuff. Count on around 4Gb. I have installed all this stuff to an 8Gb SD card. UNPACK IT TO THE ROOT FOLDER. It doesn't like being deeper.

Let it do its thing. It'll take a while.



Step 4 - patch Ubuntu

There are a few tweaks to do to get this going properly due to an irritating little bug. For example, under Windows you cannot create a file called dot-something, so when the X-windowing system tries to make a file with a name like ".lock_X0" it fails.

So open up E:\Portable_Ubuntu_TRES\bin\run_X.bat (assuming your copy was installed to E:)
Down near the end you will see a line saying:

  XWin.exe :0 -ac -notrayicon -multiwindow -dpi 100

Change this by adding "-nolock" so it reads:

  XWin.exe :0 -ac -nolock -notrayicon -multiwindow -dpi 100

Save the file, then close the editor.


The next thing is optional. Portable Ubuntu gives access to the C:\ drive from within the Ubuntu environment as "cofs2". However if you have downloaded the source package someplace else (Flash media, for example) you will need to tell Portable Ubuntu how to access it.

Open up E:\Portable_Ubuntu_TRES\config\portable_ubuntu.conf


But first this - at the top you will see:
  ## Memory that uses Portable Ubuntu in Mb.

  mem=256

  ## Swap size that uses Portable Ubuntu in Mb.

  swap_size=256

Change both of the 256's to be 512. You'll need the extra while building Qt.



About halfway down you will see:

  ## Windows drives or Windows paths that you need use in Portable Ubuntu.

  shared_folder0=c:\

simply add:

  shared_folder1=f:\

Amend "f:\" as desired.

You can add another, call it "shared_folder2", and so on.


Save the file, but DO NOT close the editor yet.



Step 5 - run Ubuntu

Open E:\Portable_Ubuntu_TRES and double-click "pubuntu.exe".

A little logo saying "Portable Ubuntu Remix" should pop up.

Give it a while to get going. After a little bit (just shy of a minute on an eeePC), you'll see the standard Ubuntu toolbar across the top of the screen.

[logo] Applications   Places   System  [firefox]  [mail]  ...etc...

Once everything has settled down, you can copy the source archive.



Now we need to set up the default root password. Take a look for the little pubuntu icon on the Windows system tray. It looks like a cross between a light brown door partially open, and a sideways semi-foldered carry bag.
Click it, and a window should open called "Console - Cooperative Linux".

Log in as "pubuntu" with the password "123456".

Now enter:

  sudo passwd root

You will be asked for the password for pubuntu, which is "123456".
Then you'll be asked for the UNIX password, twice. Type 123456 each time, so all the passwords are 123456. It's simpler that way.

DO NOT CLOSE THE CONSOLE - that shuts down Portable Ubuntu! Instead, click the tray icon again and the console will go away.



Step 6 - you're going to need spaaaaaace!

The default install leaves too little free space to be capable of building the OSD code. There is a lot of junk we don't need. Time to be ruthless. If you want to play with Linux, you'd be better off making a bootable USB stick or SD card (the Ubuntu USB installer makes this dead easy). This idea is purely to be able to build OSD software, and as such, there is no need for a lot of the software provided in Portable Ubuntu.


On the top centred panel, click "System", go to the "Administration" entry, and when the submenu pops up, click on "Synaptic Package Manager".

THE SCREEN WILL GO SCARY BLACK. Don't panic. You'll be asked to enter the root password (which is 123456) in order to allow the package manager to modify core bits of your installation.


[NOTE: if you can't type anything in the box, Alt-Tab to a Windows application (or try the Windows-logo key) to make the Windows taskbar reappear, then click on the pubuntu icon on the system tray (it is a brown/red thing like a cross between a part-open door and a folder carry bag!). This should work, but it seems that the password entry thingy isn't particularly good at capturing keypresses...]


In the window that appears, click on the "Settings" menu, then choose "Filters".

In the window that pops up, click on "New" (lower left) and name this filter "Installed" in the box on the upper left.
In the "Status" tab on the right hand side, click "Deselect All" and then click only to select the "Installed" option (under the bold word "Current").

OK this.

Once the package manager window has finished updating, click "Custom Filters" (lower left) and choose "Installed" from the list above it.

Now maximise this window full-screen. It is easier to work with.

In the quick search, look for "gnome-games".

In the list on the middle/right, click the little green box beside "gnome-games" and choose "Mark for removal". DO NOT CHOOSE "Mark for complete removal".

It will turn red.

Do the same for "gnome-games-common" and you will be asked about the removal of quite a lot of stuff. Click on "Mark" to get rid of it all.

Clear the quick search to show everything.

In the list of packages, click on the "Size" heading so the biggest things are listed first.

We wish to mark for removal:

  ubuntu-docs
  openoffice.org-core
    (and "Mark" the many that you are prompted with)
  openoffice.org-common  (and the prompted)
  evolution-common       (and those prompted)
  gimp-data              (and gimp)

You'll see some openoffice stuff, so enter "openoffice" in the quick search, and mark for removal everything that has "openoffice" in the package name.
Clear quick search to return to the full list.

  ttf-arphic-uming
  gimp-help-common
       (and gimp-help-en)
  foomatic-db            (and its engine)
  ekiga
  rhythmbox
  ttf-unfonts-core
  libopal3.6.4
  brasero
  ttf-sazanami-mincho
  libsane
                (and some other stuff)
  tomboy
  f-spot
  gcalctool
  ttf-sazanami-gothic
  cups
                   (and lots)
  brltty                 (and brltty-x11)
  cups-common            (and plenty)
  ttf-arabeyes
  ttf-thai-twlg


Now click the "Package" heading.

  bluez                  (and its bluez-gnome)
  bluez-alsa
  bluez-gstreamer
  evolution-data-server
    [we cannot get rid of evolution-data-server-common as it has
     links to the taskbar thingy at the top of the screen, the
     session manager, and so on; removing this stuff is BAD]
  evolution-documentation-en
  evolution-webcal
  example-content
  hplip-data
  xsane-common


Okay. That'll do. There's loads more we can remove - pretty much all of the multimedia stuff and codecs and associated libraries, but this claims to free up 1064Mb [which will be about 800Mb in reality - is Linux using 1000=Mb?] which will be enough for now. And I know you're bored of this...

Click the "Apply" button.
After a recap prompt, package removal will commence.

This isn't *too* slow, but it isn't too quick either. Go put the kettle on.


Done? Okay, close the package manager.


There's one last GUI thing to do before we turn our attentions to the Neuros code.

On the top-centred Ubuntu menu, click on "System", choose "Preferences" and when the submenu opens, select "Screensaver".

Regard the computer as idle after... and drag the slider all the way to the right to set the idle time to be 2 hours.
UNTICK "Activate screensaver when the computer is idle".

Click on "Close".



Step 7 - copy and extract the sourcecode

Click on "Places" on the toolbar, and then on "cofs#", where it is:
  cofs2 - for C:\
  cofs3 - for something else

It is easiest if you downloaded the source archive to the root of a Flash media, for if you downloaded to C:\ it could have been stored in all sorts of exciting locations (depending on your browser and version of Windows). But for Flash media, just click on "cofs3" and it'll be there...

[HINT: Don't put it on a USB stick with movies and pictures, or else pubuntu will spend ages making cute little thumbnails.]


The file browser will open. It is a bit like Explorer, only there's no "tree" on the left. Just a list of places.

Drag-and-drop the source archive "neuros-osd_source_22-10-2010.tar.bz2" to the part on the left that says "pubuntu".

This makes a copy on the internal "virtual drive". This is important because the Linux extfs filesystem allows permissions and stuff that aren't possible under a DOS-like filesystem (such as filenames beginning with a full stop).

On an eeePC, it'll take about 10-12 minutes. Go enjoy a lovely cup of tea. If you are like me and you go put the kettle on every time something slow happens, this might be a good time for me to mention adult-sized nappies (US: diapers). After all, a true geek never leaves the keyboard except for beverage refill. Wink

Oh, wait, what? You expected me to be serious all the way through this document? Come on!

Okay, okay, back to our scheduled programming...


Here's a painful bit. Switch to "pubuntu" (click it, on the left pane).

You'll see a copy of "neuros-osd_source_22-10-2010.tar.bz2" there.

RIGHT CLICK on that file, and somewhere in the list of things to do in the pop-up menu will be the option "Extract here" (or similar words).

Do so.

And it takes FOREVER using 7zip under Windows, so count on leaving it to get on with it *OVERNIGHT* with Portable Ubuntu.


When it is complete, delete the copy of "neuros-osd_source_22-10-2010.tar.bz2" to make more space in the image file.



Step 8 - setting up the requisites

Sadly the toolchain supplied is incomplete. There's a bunch of stuff you'll need to add in because they're more system-specific than a part of the toolchain... but they're needed all the same.

On the Ubuntu bar up the top of the screen, click on "Applications".
Follow the "Accessories" menu to open a submenu.
Click on "Terminal".

A window will appear looking a little like a basic text editor, and it will say:
  pubuntu@pubuntu:~$

This is your command prompt. That '$' is pretty much like the C:\> prompt for DOS, only the Unix shells are sexy and capable. You'll see how capable later.

Now type:

  su

and when asked for the password, enter it.

Note that the command prompt changes to be a '#' at the end. That hash symbol means you're root. Essentially a God. But probably not as cute as Kamichu. Oh well.

Now, to install the stuff we need:

  apt-get install dialog

and let it do its thing.

Then:

  apt-get install cramfs

And then:

  apt-get install qt4-dev-tools

This will download and install quite a bit of stuff, so you'll be asked to confirm. Answer "Y"es.

Then:

  apt-get install patch

And:

  apt-get install g++

This will prompt you too, as it is 6Mb of archives to install 21Mb of stuff.

Finally:

  apt-get install libncurses5-dev


Now type:

  exit

And notice your prompt goes back to being a '$'. You've been demoted from God to Regular Human.



Step 9 - setting up the compile environment

Make sure we're where we want to be. Enter:

  cd ~

and then:

  cd osd/neuros-bsp

Before all else, we have to nudge around a little bug in one of the build scripts.

  mkdir toolchain/arm-linux/usr/lib/pkgconfig/


To begin setting up the build environment, type in:

  ./setup-rootfs

Then:

  source neuros-env



Step 10 - hold your breath

If you're interested, you can load the master build script into gedit to see how capable the Unix shell is, compared to the utter lameness of DOS. But that's not why we're here. We're here for the hold-your-breath moment.

Issue the following:

  ./build-helper.sh all

and then *very* *gently* press Enter. You don't want to upset things at this point.

You'll see lots of messages as the system starts to build itself. Slowly, of course, but working. And when I say lots of messages, I'm not joking. But then if you are even doing this stuff, you've probably seen a C-based build environment in action before... I just hope your last one wasn't TurboC or you'll be in for a shock!


I wouldn't bother watching the stuff tick by. It's user inactivity time, which can only mean one thing... time to put the kettle on!


Don't leave it alone, incidentally, for partway in (about 40 minutes) you will be asked to enter the root password (123456) in order to set up the rootfs stuff for the OSD.


Note that Qt4 (the GUI system) is unpacked and built from the ground up. It would appear to do this each time you run the build script with either "all" or "external-libs". Given that it will take forever (i.e. another overnighter), you really won't want to build "all" or "external-libs" any more than you really need to.

It may be worth delving around in the build script to see how it works so you only need to rebuild that which is necessary - i.e. a minor tweak to an app won't require a total build of EVERYTHING.

Now, if you started this build process in the morning, then just leave it alone. Come back in the afternoon. If you started the build process in the evening, leave it running overnight.

If you are using a 1Gb machine, I would advise that you quit all other applications (including some of the stuff "normally resident" in the system tray), disable your screensaver, and simply DO NOT TOUCH your computer. It would appear that building Qt takes a phenomenal amount of memory...



Step 11 - ba-ding!

Eventually (after, like, forever and a day), the command prompt will reappear. It is something of a let-down, I was hoping for confetti spraying out of the screen, or something exciting.

But, then, this isn't the movies. Hacking into a Unix box to gain root access means the $ prompt becomes a # prompt, not that you'd guess that from movies where people hack in cool-looking 3D worlds with Matt Damon style avatars.

But, then again, you have what you need. You have a compiled and assembled firmware upgrade image. That's the point of all of this. And now it's done.


NOTE: What worries me is how many times the Qt SQL code reports:
      "warning: comparison between signed and unsigned integers"
      That's probably NOT what you want to see in database code! ;-)


[split because of forum length restrictions; final part follows]
« Last Edit: January 09, 2011, 03:29:13 pm by heyrick » Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 340



View Profile WWW
« Reply #1 on: January 09, 2011, 03:04:45 pm »

[the second part...]


Step 12 - where to go from here?

Chances are, for now, we'll want to try small applications for the OSD to get a feel for how this all works.

So let's start very simply.

Remember, if you have not already done so, you'll need to:
 cd ~/osd/neuros-bsp
  ./setup-rootfs
  source neuros-env



In the terminal, type:

 cd ~/osd
  mkdir our-apps
  mkdir our-apps/first-test
  cd our-apps/first-test

Now go there in the file manager:

  pubuntu (on the left) -> osd -> our-apps -> first-test

Right-click the empty pane on the right and choose:

  Create Document -> Empty File

A document will be created, with the suggested name "New file".

Change this to "test.c".

And then double-click the file.

gedit will open, displaying the empty file.


Enter into the file the following:

 #include <stdio.h>

  int main(void)
  {
     printf("Hello world - this is my first compile for the OSD!\n");

     exit(0);
  }


[HINT: Your keyboard might not do a " when you think it should. The (annoying) workaround is to press the " key and then press Space.]


And save it.


Now from the terminal, enter:

 arm-linux-gcc -o test test.c
  arm-linux-strip test

then:

 file test

which will report:
 test: ELF 32-bit LSB executable, ARM, version 1, dynamically linked
        (uses shared libs), for GNU/Linux 2.4.3, not stripped

And to see this in action? Easy.

 cp test /media/cofs2

This puts it as C:\test

From Windows, copy that file to a Flash media. I suggest this way as it makes ejecting the media less painful than dealing with two operating systems. Anyway, copy it to a SD card or something, then "safely eject" the thing and pop it into your OSD.

Telnet into your OSD.

Then:

 cd /media/SD-card

or:

 cd /media/USB

as appropriate.

If you try "test", nothing will happen. Your program is NOT broken! It's to do with the obscure Unixy can-you-run-this permissions. Try, instead:

 ./test

and have a big smile as the display looks like this:

 /mnt/tmpfs/mount_SD-card $ ./test
  Hello world - this is my first compile for the OSD!
  /mnt/tmpfs/mount_SD-card $


It might not seem like much, but we have a WORKING build environment for the OSD that runs within Windows. Yeah, we're cheatin' like hell but... you know... it just made an actual executable for the OSD.


BUT DOES IT WORK? Well, we'll need to see. I don't have my OSD set up for netbooting so I'll need to see if one of the regular developers is willing to try it out. I would, certainly, shy away from applying it as an update in case it isn't good.



IF (and only IF) you know how to NetBoot the OSD, or alternatively how to recover an OSD from a broken .upk update, then please try the stuff at http://www.heyrick.co.uk/osd/

The file dev.upk is the UPK update file.

The rest of the stuff is for netbooting. I am not sure if it is easier to use the rootfs tar, or to mount into the cramfs version, so I've posted both.

WARNING: Again. I have currently NO feedback to say if this does/does not work, so getting it onto your OSD and sorting out "what next" is something you'll be on your own with.



Let me know how you get on

Anyway, if you try this, keep in touch. Please don't ask for specific help as I'm not so good with Linux (hence the co-Windows preference). Try the OSD forums at:
  http://forums.neurostechnology.com/index.php


Or for a personal chat, suggestions, ideas, fixes, etc:
  heyrickmail [dash] generic [at] yahoo [dot] co [dot] uk



==============

This file is (c) 2011 Rick Murray.
Released under the EUPL v1.1 (only). It's a GPL-alike without the horrible v3 restrictions and gibberish, see:
  http://ec.europa.eu/idabc/en/document/7774.html

Last update: 2011/01/09, 19h48 CET
« Last Edit: January 09, 2011, 03:28:35 pm by heyrick » Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 340



View Profile WWW
« Reply #2 on: February 01, 2011, 11:12:33 pm »

Hi,

It is 05:10 (am) here, and I've just been pulling my hair out.

So I thought I should add, if you're a wally (like me) and you shut down pubuntu incorrectly, there is a chance that pubuntu will refuse to boot, forevermore.

I don't know if this is a problem with pubuntu in general, or if it was blind random luck, but just in case, I will describe what happened.

Basically, the loading of pubuntu started, the little icon appeared. And nothing. And nothing. And lots of nothing.

So I click the systray icon for the init console. I see a lot of gibberish about mount options, followed by a whinge about /etc/fstab being corrupted, followed by a statement saying waiting for /dev/cobd0 and then a statement saying waiting for -e. Then it said to press ESC for a recovery console.

To cut a long story short, there was a bogus "-e" entry in the fstab file, so the system was trying to mount "-e" and freaking over it.

Press ESC and tap in the root password (should be 123456 if you've worked through my info above).

Now, the system is in mild-panic mode, so the main drive is mounted read only. Not much help if we want to get in and fix things.

Type:
  mount /dev/cobd0 / -o remount

You should now have read/write access. This is vitally important as we don't have an option to boot from LiveCD or anything, and a complete reinstall because of a moment of brain-dead activity is, frankly, too grim to contemplate.

Now to fix the file, we are going to use the most god-awful text editor around. Okay, it's a small cut above EDLIN, but DOS users were smart enough to dump that in the '80s. Unfortunately not only is vi still kicking, but my writing this paragraph could start a war as some people just seem to revel in doing things the hard way.

Anyway, enter:
  vi /etc/fstab

You'll see some gibberish, and down the bottom, the offending '-e' line.
Move the cursor to the start of that line and press 'd' followed by Space. You'll see one character vanish. Keep on doing this until this line has been erased.
Now press ':' and then press 'w'. This will write the file to disc.
Now press 'q' to get the hell out of vi (come on guys, what's wrong with a proper full screen editor? are you telling me you can list a directory with pretty colours but a worthwhile editor is too much?).

Now type:
  exit
to quit the recovery stuff. You'll be tossed back to the boot sequence which should resume, and work.

If it does not, or if this problem is different to what you see, good luck. I ought to be fixable (unless you have epic-failed and "oops" deleted the rootfs.img file!), but finding out exactly how could prove difficult.

Just remember - always shut down pubuntu properly!

It may look like a bit of software running under Windows, but its filesystems should be treated with the same respect you give your primary system. Closing the application and then letting Windows force-kill it because it doesn't respond in 0.1sec is about the same as shutting down your PC by yanking out the power cable. Just... don't.


Phew. What a palaver. I need a cuppa...


Best wishes,

Rick.

[edit because I wrote this on Opera with scripting disabled, as I quit my usual Firefox in order to make room to load pubuntu, because my Firefox has a dozen+ active tabs and... uhhhh... it's a long story...]
« Last Edit: February 01, 2011, 11:18:12 pm by heyrick » Logged
greyback
Administrator
Hero Member
*****
Posts: 1639


View Profile
« Reply #3 on: February 02, 2011, 07:35:40 pm »

Ouch, nasty. Your drive is a SSD, right? Sometimes I wonder about their behaviour when you are a little rough.
Good guide tho!
-G
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 340



View Profile WWW
« Reply #4 on: February 02, 2011, 10:05:26 pm »

Ouch, nasty.

Yes, it was. As a fairly Unixy newie, I stared at that message and thought several unprintable things. Been a while since I've done low-level data recovery, and that was under RISC OS which is positively friendly in comparison to x86-based systems.


Quote
Your drive is a SSD, right? Sometimes I wonder about their behaviour when you are a little rough.

If you mean the pubuntu drive, it is an image file. Just a regular file under Windows which a clever bit of software mounts as if it was a real harddisc. Even so, with an extfs system, you have to shut it down gracefully.


All of the kit on my eeePC is SSD. Either genuine SSD, USB sticks, or SD cards...

As for their resiliance, the computer fell off the bed (I fell asleep, boring movie!) when it was but a baby. Plus I've used it on my lap in the car on bumpy country roads. Suffice to say I would be surprised if a real harddisc was able to survive that. It will be interesting as the SSD wears out to see what happens. In theory it should start blocking off sectors as "bad", with an ever-increasing amount, which will depend upon the number of writes to that specific bit of the flash. Wear-levelling ought to make it last a length of time comparable to a modern harddisc (what's the "official" life? 3 years?). I have only had one harddisc that failed little by little. The rest just one day stopped working (motor failure, 'stuck' internally, servo failure, and head crash from aged platter substrate flaking off).

In addition, SSDs take very little power - I can get 5-6 hours out of this machine (mom gets maybe an hour and a half). The downside is a 32Gb SSD costs the same as a half-terrabyte harddisc. Meh.


But, then, when you said "rough" you probably didn't mean in the physical sense. Can you point me to a common modern read/write filesystem that doesn't need proper shutdown? I've seen RedHat panic at a power loss and fsck everything in sight. I've seen NTFS lose track of reality so XP blue-screens next start with UNMOUNTABLE BOOT VOLUME (fix: Get Hirren's BootCD, use it, run ntfschk - why Microsoft didn't build this in as a default...). Those of us of a certain age will remember SCANDISK invoking itself, a lot. And even on the OSD it is recommended to "Eject" and not just pull out the media. What do you think would happen if I was running OSDng and I pulled out the CF? I don't plan to find out, and I wonder [in the case of power cuts, etc] how often it self-checks.


Quote
Good guide tho!

Thanks. As I said, I was pulling my hair out, so I figured on writing a guide so if this affects anybody else...


Best wishes,

Rick.
Logged
Lexsam
Newbie
*
Posts: 3


View Profile
« Reply #5 on: June 17, 2011, 02:56:10 am »

Whew! you really exerted some effort to give those tips! Great job!
Logged
Carlosan
Newbie
*
Posts: 2


View Profile
« Reply #6 on: December 06, 2014, 02:58:29 am »

Quote
I decided to give a hand and sent a post into social bookmarks. I hope the popularity will rise in.


I think it is absolutly impossible.



iphone 6 plus schutzhülle
« Last Edit: December 07, 2014, 03:25:34 am by Carlosan » Logged
Pages: [1]
Print
Jump to: