Alexander G. Ororbia II

From FINSwiki
Jump to: navigation, search

Contents

Groundwork (May 21 - May 25)

  • Figured out the general process for building Android platform for various devices and began looking various issues that could potentially crop up
  • Began basic outline/schematic for build process


Source(s): Alexander G. Ororbia II


Basic Process: Android Platform Development

  1. Build in the Linux environment, will need, using the sudo command: (http://source.android.com/source/initializing.html)
    1. Install Python 2.5 -- 2.7, which you can download from python.org. Repo is only compatible with Python 2.x
    2. Install GNU Make 3.81 -- 3.82, which you can download from gnu.org,
    3. Install JDK 6 if you wish to build Gingerbread or newer; JDK 5 for Froyo or older. You can download both from java.sun.com.
    4. Install Git 1.7 or newer. You can find it at git-scm.com.
    5. Install various packages
    6. Configure USB devices (I believe I already have the required access)
    • Could use Ccache, which speeds up rebuilds and if "make clean" is used often (supported only for Ice Cream Sandwich and later)
  2. Download the source/build code: (http://source.android.com/source/downloading.html)
    1. Need to configure Repo, which works with GIT repository
    2. Need to initialize Repo client to access source code repository, and get the files from "manifest" (repo sync command will take about 1 hour to acquire source files)
    3. Will need to use authenticated access to prevent quota cut-offs, also check for network issues (are we using a proxy?), consider building from a local mirror for low bandwidth requirements in network?
    4. Verify public GIT tags/keys
  3. Building the code system: (http://source.android.com/source/building.html)
    1. Initialize the environment for code, choose "lunch full-eng" for developer config with debugging
    2. Build the emulator with "make -jN" with N = the # processors available to use in building and run the emulator with "$ emulator"
    3. Put ccache in root of the source tree to make builds faster
    4. Flash the emulator to a device when needed
  4. Specific Device Information (http://source.android.com/source/building-devices.html)
    • Devices Supported : Galaxy Nexus, Motorola Xoom, and Nexus S, may need to add the adb (?)
    • Will need to unlock the bootloader for Nexus S, Galaxy Nexus, Xoom in order to flash a custom system
    1. For IceCreamSandwich on Nexus and S and Xoom , will need to include binary libraries to run with pure source code and should be included in the master branch (each comes with self-extracting script, but need to run "make clobber" first), may need to check what bootloader is used for Nexus S and Galaxy Nexus (consult tables)
  5. Relevant Issues to be aware of/debug:
    1. Difficulties syncing the source tree (VirtualBox Ethernet issues).
      • Symptom: When running repo sync in some VirtualBox installations, the process hangs or fails with a variety of possible symptoms. One such symptom is DownloadError: HTTP 500 (Internal Server Error: Server got itself in trouble).
      • Cause: The default network behavior of VirtualBox is to use NAT (Network Addrss Translation) to connect the guest system to the network. The heavy network activity of repo sync triggers some corner cases in the NAT code.
      • Fix: Configure VirtualBox to use bridged network instead of NAT.
    2. Build error with 4.0.x and earlier on Ubuntu 11.10. (See documentation)


Source(s): Alexander G. Ororbia II


Tuesday, May 29, 2012

  • Set up research log
  • Uploaded previous week's groundwork notes to wiki
  • Investigated what builds are available for what Android devices (Nexus S, Galaxy Nexus, Motorola Xoom)
    • What device drivers are available and open-source or binary?
    • No official binaries exist for Nexus 1, ADP2, ADP1
  • Required binaries for Nexus S Android 4.0.3 (IML74K):
    • AKM Orientation Sensor; Broadcom Wifi, Bluetooth, and GPS; Imagination Technologies Graphics driver; NXP NFC; and Samsung GSM
  • Required binaries for Galaxy Nexus (GSM/HSPA+) binaries for Android 4.0.3 (IML74K):
    • Broadcom Wifi, Bluetooth; Imagination Technologies Graphics; Samsung GSM
    • Note for Galaxy Nexus: Galaxy Nexus is supported only in GSM/HSPA+ configuration "maguro" and only if it was originally sold with a "yakju" or "takju" operating system.
  • Required binaries for Motorola Xoom (US Wi-Fi) binaries for Android 4.0.3 (IML74K):
    • Broadcom Wifi, Bluetooth; nVidia Graphics
  • Known Issues or Problems Building For Various Supported Devices


Source(s): Alexander G. Ororbia II


Wednesday, May 30, 2012

  • Set up new workstation for research work
  • Read up on and set up VirtualBox virtual machine, the environment inside inside which the Android platform will be developed
  • Long-term plan for Android platform development:
    • Set up on VirtualBox a basic build environment (up to the point before source code will be downloaded for each device)
      • Including the installation of basic required software/packages (i.e. Java 6, Python 2.x, etc.)
    • Create 3 mirrors of this basic build environment
    • In each mirror, continue the building process for each supported device: Nexus S, Galaxy Nexus, and Motorola Xoom
      • Investigate and document the issues and advantages in building each
      • Integrate the required proprietary binaries
    • Integrate current FINS kernel code into each Android build
      • This is where the challenges should come!
      • Figure out how to get the modified package to run and create a final system image (for redistribution)
      • Issue: May have difficulties getting permission from the various companies involved to include the proprietary code in the redistribution
  • Useful Ubuntu Commands:
  • Will need to use VBoxHeadless, the remote desktop server to perhaps reduce latency resulting from connecting to VM through SSH


Source(s): Alexander G. Ororbia II


Thursday, May 31, 2012

  • Successfully connect to virtual machine via Xmanager + SSH directly to FINS server
    • Goal: Simplify this process so that user can directly connect to VM via Xmanager
    • Goal: Allow for the VM to exist/run outside of terminal/remote client, i.e. the VM can still run even when user closes terminal window (to allow for builds to run even when closed)
  • Connected to FINS network and to the created VM for Android Development
  • Want to begin platform building


Source(s): Alexander G. Ororbia II


Friday, June 1, 2012

  • VirtualBox direct connection and background run
    • Will need to use VBoxHeadless, the remote desktop server (For more info, see: https://www.virtualbox.org/manual/ch07.html#vboxheadless)
    • Note: The idea is to have the "AndroidVM_basic" that I generated/cloned running all the time in background on the FINS server without a graphical interface (especially useful for allowing builds to compile over the hours in the background), but we can still connect to the VM remotely (i.e. access the graphical desktop so as to actually do platform development) from even other machines
  • Picked up a few useful little tools for getting required network information
    • Linux host command
    • Also "/sbin/ifconfig -a | less" gets network information, and one needs to look at em1 or em2 (under bond0.9) for the relevant IP and network information
    • the IP identification site: http://www.whatismyip.com/
  • Successfully set up the direct connection required to access VBox "AndroidVM_basic"


Source(s): Alexander G. Ororbia II


Directions to set up a remote display connection to VM for Android development

  • This is a condensed, quick reference guide to setting up a VM on the fins.bucknell.edu server for remote connection (most recent versions of VirtualBox support VRDP), for more detailed information (especially relevant to other RDP's) see: https://www.virtualbox.org/manual/ch07.html#idp16483152
  1. Set up VM machine in VirtualBox (memory, number of CPU's, other relevant properties)
  2. Log into FINS server and move into the /home/fins directory
    • I used Xmanager, then used ssh to indirectly enter the FINS network to ultimately gain access to the VM
    • Important Note: At this point, I used the following command to obtain the IP address of the host network where the VM I wanted to connect to remotely existed
     host fins.bucknell.edu 
  3. Run the command to access the graphical interface for the software
     $ virtualbox 
  4. Select the appropriate non-running/powered-off VM (or you will have to access the settings within the VM desktop) and right click "Settings" to gain access to the primary properties of the VM and just click the OK for the error dialog that comes up regarding the USB subsystem (unless you need USB access)
  5. Select "Display" on the left column of the GUI, and then select the "Remote Display" tab
  6. Check off the "Enable Server" and note the auto-generated server port number (VBox default is 3389) and click OK to save these settings
  7. At this point, exit out of VBox and run the command:
     $ VBoxManage startvm AndroidVM_basic --type headless 
    • This command runs VirtualBox but as a headless server, where the VM you choose (in my case, "AndroidVM_basic") will run on the server but without graphical interface to the desktop
  8. An RDP (Remote Display Protocol) viewer will be needed to actually access the headless VM remotely, in my case, I used Windows 7 "Remote Desktop Connection" (RDC)
    1. In Windows 7 RDC, enter the IP address of the server you are connecting to, followed by the port number obtained in VirtualBox for your VM, in the form "xxx.xxx.xxx.xxx:XXXX" (i.e. IP address followed by a colon that precedes the port number)
      • Just click Yes if you get the dialog that appears right after saying that Windows RDC could not identify the remote computer
    2. If everything was set correctly, the graphical desktop to the virtual machine you are trying to connect remotely to should now appear (with a login screen or some form of authentication)


Source(s): Alexander G. Ororbia II


Monday, June 4, 2012

  • Tested AndroidVM_basic VM
    • Confirmed that the VM runs independently (in headless mode) on the FINS server (shut down workstation for the weekend and found that system was still up and running when trying to connect today)
    • Windows RDP works well in connecting to AndroidVM_basic, so the work environment has been set up for Android platform development
  • Set up extra layer of security to enter AndroidVM_basicV2 (the replacement for the original machine, which was possibly compromised)
    • Ended up using VBox external authentication (not simple authentication), which works in conjunction with Linux PAM system


Source(s): Alexander G. Ororbia II


How to Configure VM Authentication Method (VirtualBox)

  • For full details, see: https://www.virtualbox.org/manual/ch07.html#vbox-auth
  • In the "Remote Display" panel of the Display Tab found in the VM's settings, go to selection method and choose "External" ("Guest" was not supported at the time of this research project)
    • Alternatively, configure these settings via the command line:
     $ VBoxManage modifyvm <NAME_OF_VM> --vrdeauthtype external 
    • To select the kind of authentication library VirtualBox uses, you will need to specify with the following command:
  $ VBoxManage setproperty vrdeauthlibrary VBoxAuth // This line will authenticate against the user credentials defined by the host
  $ VBoxManage setproperty vrdeauthlibrary VBoxAuthSimple // This line will authenticate against the user credentials defined by the host 
  • VirtualBox Bug: Using host-dependent credential verification should allow multiple users who have credentials stored in the host to log into the VM remotely, however, VirtualBox at the time of this writing has an bug (something that has existed since about Version 3.x.x) or defect, where only the user that set up the VM/ran the VM (in headless mode) can log onto the VM remotely. It was decided that this was a sufficient enough security model, as only now 1 account can access the VM
  • Simple authentication could prove to be useful, and I speculate that toying with this later to address the VBox bug. Following these steps, a user can be manually authenticated and credentials can be added in by the developer into the "extradata" section of the VM's ".vbox" XML file.
  $ VBoxManage internalcommands passwordhash PASSWORD // VBox will print out a the password run through its own hash function (salted, I believe)
  $ VBoxMange setextradata <NAME_OF_VM> VBoxAuthSimple/users/<userName> <HASHED_PASSWORD> // This actually puts the user into VBox's records


Source(s): Alexander G. Ororbia II


Useful Tricks to Ease the Authentication Setup Process

  • Security/authentication logs were located within "/var/log/secure" (for Fedora Red Hat, the location of the "secure" file will be different depending on the underlying OS)
    • The location of the logs can be determined by running:
  $ /etc/rsyslog.conf. # Where log daemon configuration is at

  # Note:  Use the "more, less, head, tail" for better file navigation

  $ tail -30 /var/log/secure  # display last 30 lines of file
  $ tail -f /var/log/secure  # display end of file and keep file open


Source(s): Alexander G. Ororbia II


Tuesday June 5, 2012

  • Helped Bashar understand errors with Android server/client program (enlisted aid of Brian King), helped to debug and trace source of error
  • Created 3 mirrors of the AndroidVM_basic for platform work to be done on the 3 different supported phones
    • NexusS_platform, GalaxyNexus_platform, Xoom_platform


Source(s): Alexander G. Ororbia II


Directions for Setting Up the Final Platform (Base)

  • Useful Command: $ df //displays memory (file system) statistics, and memory partitions (also check out "$ sudo apt-get install gparted")
  • For installing JDK 6 for the Android platform environment, needed to run the command:
 $ sudo apt-get install openjdk-6-jdk // Need this since Sun was bought out by Oracle 


Source(s): Alexander G. Ororbia II


Wednesday June 6, 2012

  • Continued with Android platform development
  • Trip to Virginia Tech for conference (June 6 through June 8)
  • Found error in configuring REPO, there's a missing Python module called "ReadLine"


Source(s): Alexander G. Ororbia II


Thursday June 7, 2012

  • Lessons and understandings from V-tech conference pertaining to FINS and the Android component of the project:
    • See notes (to be transferred)
File:Flow-diag.jpg
This should be a flow-diagram I made at the conference, would like to upload it!!!
  • Notes
    • FINS solves the modern network issues with mobile wireless (accessing the protocols without messing with the kernel and recompiling it)
      • Before, networks were of a "nomadic model" where a user would sit and then use his computer, and then move to another spot, whereas today a user will use his or her computer while moving (on mobile device for example)
    • Terms:
      • Cross-layered approach = structures to preserve modularity while enabling new interactions
        • Better for wireless networking instead of the monolithic stack model (which has been used for the wired model)
      • Mesh networks (ad-hoc, multi-hoc), MANET (Mobile Adhoc Network Environment)
    • GOAL for FINS: build the framework for modular, extensible, experimental network stack implementation to run real-world network experiments (no longer limited to network simulations), lower overhead/logistical troubles for researchers (no kernel learning curve or limited by LINUX/BSD standard) and make modification of protocols easier (and the development of heterogeneous networks), replace socket family (in LINUX kernel) and keep the resource management aspect of the kernel and essentially "pretend" that FINS (in user-space) is the network stack (FINS Wedge --> picks up the system calls of the kernel layer)
      • In FINS user space, the FINS core is made up of the socket stub (consists of the socket daemon and the FINS Wedge) and the switch thread (switches between modules, or protocols)
      • Task 1: FINS on mobile
      • Task 2: TCP/IP protocol stack (compliant with standards but transparent and controllable), add IPv6
      • Task 3: Apply FINS to a demo and perform experiments in MANET, WiFi driver/stub important to consider
      • Task 4: Develop/distribute course modules (promotion), FINS design competition and workshop (like MANIAC)
    • Discussed potential bug-trackers: GitHub Issue Tracker, Bugzilla/JIRA, Google Code Hosting
    • Android Build Process (Simple):
    1. Download and modify code tree (kernel and platform)
    2. Build tree (kernel/platform creates single, read-only system image file
    3. Load system image onto device
    4. Boot and run


Source(s): Alexander G. Ororbia II


Friday June 8, 2012

  • Researched and contributed a network experiment idea to the conference/meeting to advance and demo FINS
    • Measure power consumption (develop a power profile) or CPU cycles (processing speed) for each node in 30 to 40 mobile device node network, perhaps using different transmission protocols (i.e. TCP, UDP, IP, ARP, etc.)
      • This idea needs to be better sketched out/conceptualized, good exercise for scientific computing experimental design for future graduate work
      • In regards to protocols, could measure a given protocol's energy consumption behavior over a wireless network (and suggest improvements to TCP code to reduce protocol processing and software overhead) --> focus on power or processing efficiency among nodes in a network system
    • Power/Measurement Profile: CPU, memory, touchscreen, graphics hardware, audio, storage, and various networking interfaces
    • General References (that sparked idea):
    • Rudimentary Proposal: This FINS experiment/data collection could be done under a classroom setting or for one of the FINS course modules discussed (in V-Tech or Bucknell) and the devices could be given to the students to use (these students in particular would be more interested in the data and perhaps use the devices the best to facilitate the experiment/data collection)
      • Solves the personnel problem (don't need to spend money hiring experimental subjects, or search for volunteers, and test subject pool can be generated quickly)
      • Experimental setup could be casual/flexible (students are free to live their daily routines over a span of time over which the data is collected) or something more rigid and controlled like the MANIAC gym set-up


Source(s): Alexander G. Ororbia II


Questions and Points to Address

  • Do Android device drivers work similar to those on Linux kernel? (SoftMAC and device driver), what meters and knobs exposed through these drivers
    • Unify Linux and Android device driver functionality?
    • if generic netlinks are supported on Android kernel?
  • Concepts to Focus On:
    • Protocol Modules (ARP, ICMP)
    • Android Stuff?
    • WiFi Stub
    • Configuration/initialization and control process (Abdallah)
      • What's the FINS start-up process? (maybe for Version 1.1)
      • Config file outlining what modules and such to load and initializes/configures them (set start parameters, etc.)
      • Switch Table config (modules)
      • Load/start modules
    • Socket stub (current and future replacement)
    • Demonstration and experiments
  • Develop build-process documentation, including information pertaining to device drivers, steps to making final image (how much of the process will be scripted/automated?)
  • Version 1.0 of FINS
    • DUE: this summer 2012
    • Needs licensing
    • ARP --> basic functionality, multi-interface support
    • Application testing complete
  • General (Refined) Task for summer:
    • Android Platform development
      • Figure out every detail of build process, including device drivers, DEADLINE: build basic mobile device platforms within ~2 weeks
        • Device drivers? --> works directly with Jonathan Reed's WiFi stub development
      • Integrate FINS kernel code into Android build, figuring out where everything fits
      • Integrate Major's native app code into the build process (User-Space FINS)
  • Version 1.1 of FINS
    • DUE: September 2012
    • Contains configuration file developed by Abdallah
    • Contains protocol modules ARP (and ICMP) support, IP Control and IP Forward
    • Is available as an Android mobile image
    • Contains developed WiFi stub
    • Contains developed Socket stub


Source(s): Alexander G. Ororbia II


Task Allocation for Near Future

  • Abdallah --> adaptive video stream project, start-up config file
  • Guythri --> ARP, ICMP, IP Control, IP Forward
  • Jonathan --> Version 1.0 of FINS, TCP, Raw socket support, be able to do pretty much Bucknell's Android research himself, Socket stub, WiFi stub
  • Alex --> platform build, transfer all this knowledge to Jonathan and Major
  • Bashar --> extend/work with Kevin's code, ESM and API's for applications
  • Major (Alex M.) --> native code development, make FINS compile/build (with or without Java front-end) and run on Android

Monday June 11, 2012

  • Continued Android Platform development/building
  • Updated Wiki with information/notes from research conference
  • Will also need to think about writing automation scripts to simplify the building process for the user
    • Will the image be in the form of a downloadable (pre-loaded) Virtual Machine?
    • Will image be a downloadable, modded Android tree?


Source(s): Alexander G. Ororbia II


Tuesday June 12, 2012

Android Build Process (Using the Master Tree)

  1. There is no need to install Python as the directions suggest IF you are using the Ubuntu 10.04 environment (it was configured through and run via VirtualBox in this project's context) as the Python distribution (Python 2.6.5) that comes with this version of Ubuntu (simply run $ python --version to discover what version is packaged) works best TO circumvent several problems that crop up by trying to install a newer version of Python
    • Known Issue: In AndroidVM_basicV2, I went through the build process installing Python 2.6.8. However, when I came to the source code downloading stage, running the following command produced the following error (shown right below the command):
       repo init -u <code>https://android.googlesource.com/platform/manifest</code>''' command failed and produced the error: 
 Traceback (most recent call last):
  File "/home/bucknell/bin/repo", line 91, in <module>
    import readline
ImportError: No module named readline
    • Not sure how to deal with this error, however, it has something to do with the fact that the readline module (and header file) is not set up in more recent versions of Python (such as my choice, Python 2.6.8)
  1. There is no need to install GIT as suggested given that Git Version 1.7.04 comes with the Ubuntu 10.04 image
  2. There is no actual need to install GNU Make, given that GNU Make 3.81 comes with Ubuntu 10.04, however, I installed GNU Make 3.82 in the AndroidVM_basicV3 machine
  3. See my previous notes on installing JDK 6
  4. When running the repo init command, when prompted to provide a username, I chose to provide a name with no space delineating the first and last name (as per a weird quirk pointed out in one forum, however, there is no proven benefit to this naming convention)
  5. One primary issue comes up during the repo sync stage, here is one major correction needed to fix the network problems associated with VirtualBox:
    • With the VM shut down, you need to enable the DNS proxy (which ultimately will forward requests to the--local--server on which the VM exists), run the command:
      $ VBoxManage modifyvm "AndroidVM_basicV3" --natdnsproxy1 on //Replace AndroidVM_basicV3 with the name of your virtual machine 
    • Primary Source with this work-a-round in context: https://forums.virtualbox.org/viewtopic.php?f=1&t=47774
    • This solves the timeout issue or the intermittent connectivity that VirtualBox experiences over a span of time (you can test the connectivity either through pinging or by running the command host www.google.com multiple times and observe when it does work and when it does not)
  6. After addressing these particular issues, you should finally be able to run repo sync
    • Note: Alternative commands to try include:
      $ repo sync -f // This forces the syncing process to continue regardless of networking issues/errors 
      $ sudo sysctl -w net.ipv4.tcp_window_scaling=0 // Tweaks TCP settings 
      $ repo sync -j1 // This is a good idea to try after tweaking the TCP protocol settings 
  7. Entered Git Public Key so future Git tags can be verified with:
     $ git tag -v TAG_NAME 
  8. NOTE: Not such a great idea to clone the baseVM with the full Android tree built (best to do so near the start)


Source(s): Alexander G. Ororbia II


Useful Linux Administration Commands (That Help with the Build Process)

  • This is useful to try in combination:
$ history // This will display on the terminal window all the commands the user has entered in the terminal
$ history | grep <some character pattern like "PATH"> // This takes the output of the "history" command and runs it through a pipe, 
                                                      // where the "grep" command will search through the output for the 
                                                      // specified pattern
$ history | grep -i <some char pattern like "PATH"> // -i makes this a case-insensitive search (which means you could type "path")
$ !<number> // Replace <number> with a # on the left-hand column of the commands displayed via "history" to use/run that specific 
            // command without retyping (in Linux slang, this is known as "bang")
$ !! // This runs the most recently entered command
$ !! -l // This is the syntax for appending to an old command such as "ls" (which means one can combo commmands with this syntax)
$ host <URL/hostname/servername> // IP address look-up
$ ping <IP/hostname> // This sends a ping packet to the desired server (useful for testing connectivity)

General Linux Commands to Know

  • Use CTRL + Z to halt what's currently going on (if infinite loop), more effective than CTRL + C, then run:
$ kill %1 // This kills the last run process 


Source(s): Alexander G. Ororbia II


Wednesday June 13, 2012

  • Continued platform development
  • Android basic tree for the Nexus_S_platform was finally built (a few tasks remain to augment this platform), with the command: $ make -j16 (for 16 threads since I had four processors on the VM)

Networking Bug with Virtual Machine

  • Bug: When I reconnected to the virtual machine this morning, there was no network connectivity. It seems that after shutting down the VM or exiting the current RDP connection, the network connection was disabled, the reason for this is unknown at this time
  • Fix: Place the cursor over the "Wired Network Connection" icon at the top of the window (the Up/Down arrow icon), and first right-click and select "Enable Networking", then left-click the same icon to select "Auto Ethernet", and network connectivity should be reestablished

JDK Compatibility Bug

  • Bug: There is an issue with the currently available JDK 6, the open-jdk-6 that I was able to install Android does not want to play nice with, it gives me the following error, most likely expecting the exact package that was once available through Sun Microsystems (before that was bought out by Oracle):
************************************************************
You are attempting to build with the incorrect version
of java.
 
Your version is: java version "1.6.0_20".
The correct version is: Java SE 1.6.
 
Please follow the machine setup instructions at
    http://source.android.com/source/download.html
************************************************************


Source(s): Alexander G. Ororbia II



Source(s): Alexander G. Ororbia II


Thursday June 14, 2012

  • Will need to keep track of memory (space) taken up by each build as well the overall flow/speed of the build process
    • Possible build paths:
      • Build the master branch for each device, then insert the phone-specific device drivers
      • Build the specific phone branch (i.e. "crespo" for NexusS, etc.), then insert phone-specific device drivers
  • Continued with Android platform building
    • Nexus S will require GSM (Global System for Mobile Communications) configuration "crespo"
    • Inserted appropriate device driver binaries and ran self-extracting scripts (and read through license agreements)
    • Had to re-make master build to take into account the proprietary binaries, ran the following commands to ensure that the "adb", "fastboot", and device drivers are included in the Android build:
      $ make clobber 
      $ make fastboot adb -j16 
  • Useful "adb" information: http://developer.android.com/guide/developing/tools/adb.html
  • After work yesterday, picked up Linux Administration pocket book


Source(s): Alexander G. Ororbia II


VirtualBox USB Connection Issue

  • It is important to add yourself to the vbox users group that has access to the USB ports, or else, you cannot flash to the Android device
    • Use the command, and edit the file by putting in your username in the appropriate group:
      $ vim /etc/group 


Source(s): Alexander G. Ororbia II


USB Access Issue

  • Problem: Cannot flash Android Nexus_S image to phone b/c the VM Nexus_S_platform exists on the FINS server, and thus the VM looks for USB access of the actual FINS server computer
  • Solutions:
    • Could plug in phone directly into the server computer itself
    • Could use VRDP, a feature of VBox that allows the VM to access the USB of the remote computer connecting to the virtual machine
      • Does Windows RDP have such capability? Adding drives to the session?
        • Doesn't look like it (adding drives, including the plug-and-play section does not seem to affect the RDP session)
      • Could install Ubuntu 10.04 on a laptop, install VirtualBox, run the rdesktop RDP program with VRDP enabled and plug in phone into that laptop
        • Ubuntu 10.04 has Remote Desktop Viewer
    • Could find what actual output files does the Android build process boil down to, and try bootloading and flashing on the actual physical Windows 7 computer I have been using (using Windows command prompt)
      • Not clear where the build process puts the final image files or actual output that goes into the phone


Source(s): Alexander G. Ororbia II


Friday June 15, 2012

  • Made the Galaxy_Nexus_platform VM clone and went through its build process
    • I think the way to go about building properly is to run a set of two make commands:
      $ make fastboot adb -j8 // Makes the fast bootloader and the debug bridge, takes a short time 
      $ make -j8 // Takes much longer, does the whole build from what I understand 
  • Made the Xoom_platform VM clone and went through its build process
  • Continued to investigate the results of the Android build process to see where the actual output image files exist (posted this to a forum as well to see what comes up while I search)
    • Looks like maybe this: Install system fs image: out/target/product/generic/system.img
  • Set up little netbook to run Ubuntu 10.04, which will serve as my RDP remote computer
  • Immediate Goal:
    • Get the build to successfully work on a NexusS phone
    • Get a build going for Galaxy Nexus and Motorola Xoom
    • Purchase Galaxy Nexus and Motorola Xoom phones


Source(s): Alexander G. Ororbia II


Tip: Avoid Crashing the Server with Virtual Machine Processing

  • DO NOT run multiple VM's running the Android build process at the same time (especially if you're server is 16 G of RAM and you're running 2 VM's with a maximum of 8 G RAM each) --> or you will see that both VM's were killed by the server after making it thrash a bit (each will be shown in VBox in the "Aborted" state)
    • Good command to know to preserve the console output of the build process (so you can check how far it got before crashing):
      $ ls asdf > /tmp/ls.out 2>&1 // This is a sample format, but this will direct the output to a text file for later viewing 


Source(s): Alexander G. Ororbia II


Monday June 18, 2012

  • Pursued the alternative solution of laptop with Ubuntu and VBox to flashing Android to Nexus

Setting Up a NetBook as a Remote Portal to VM

  • After installing the Ubuntu 10.04 OS system image, needed to configure networking settings to enable wireless access (need to install appropriate driver)
  • Needed to configure the remote display settings of the VM with:
$ VBoxManage controlvm Nexus_S_platform setvideomodehint 800 520 16 // replace "Nexus_S_platform" with the name of VM and the 
                                                                    // settings go in the order <xres> <yres> <bytes_per_pixel>,
                                                                    // the settings of 800x520 fit the full VM window within the 
                                                                    // leftover space I had in the netbook 


Source(s): Alexander G. Ororbia II


USB Connection Bug--Messes Up the Flashing-to-Device Step of Build Process

  • Bug: There is major issue with getting the VM to actually recognize the USB port in which the Android Nexus phone plugs into (in fact, a similar problem occurs with any plugged-in device such as a USB mouse)
  • Attempt at Solution: Working with Mr. Dreese, was able to get the rdesktop-vrdp to log down the plugging in of an Android phone device (appears in the VBox logs), however, the VM within VirtualBox does not display or seem to recognize the device (had to reboot phone and computer to even get this attempt to work the way it is currently described) (Note: added ago004 to VBoxusers group on the local netbook machine)
  • Solution (Actual): Well, about that......


Source(s): Alexander G. Ororbia II


Questions Posted


Source(s): Alexander G. Ororbia II


Tuesday June 19, 2012


Source(s): Alexander G. Ororbia II


Useful Linux/Ubuntu Commands


Source(s): Alexander G. Ororbia II


Byte Conversion Notes

  • Given the nature of the work, it is important to remember these byte conversion rules:
Here are the basics:

1 byte = 8 bits
1 kilobyte (K / Kb) = 2^10 bytes = 1,024 bytes
1 megabyte (M / MB) = 2^20 bytes = 1,048,576 bytes
1 gigabyte (G / GB) = 2^30 bytes = 1,073,741,824 bytes
1 terabyte (T / TB) = 2^40 bytes = 1,099,511,627,776 bytes
1 petabyte (P / PB) = 2^50 bytes = 1,125,899,906,842,624 bytes
1 exabyte  (E / EB) = 2^60 bytes = 1,152,921,504,606,846,976 bytes

So the formula for conversion are:
X KB = NumberOfBytes/1024
X MB = NumberOfBytes/1048576 OR X MB = NumberOfBytes/1024/1024


Source(s): Alexander G. Ororbia II


Wednesday June 20, 2012

  • Successfully found one path to manually flash the Crespo system build to the Nexus S phone
  • Re-built the Android platform for the Galaxy Nexus phone on the Galaxy_Nexus_platform
  • Built the Android platform for the Motorola Xoom on the Xoom_platform
  • Next Goal: Dissect the Android build process to find out where the file system tree/compiled code is put, so we can perhaps package that, separate from the device driver code and give the end-user of the FINS-Android build a package that completes the build process from that step
    • In essence the process would combine the compiled code, the modifed FINS-Android-kernel, and an extraction script that would go to the Google Nexus download site that has the device drivers --> this allows us to distribute FINS-Android without actually distributing the proprietary device driver code (leaves this up to the individual user)

ROM-Flashing to a Nexus S Device from a Virtual Machine Android build


Source(s): Alexander G. Ororbia II


The Guided Process

  1. Install the Android SDK onto a netbook/laptop loaded with an Ubuntu 10.04 OS (I also had VirtualBox installed on it)
    1. Found and downloaded the Linux version of the Android SDK, and via the Android SDK Manager, one can select what is needed but it is important to select the "platform_tools", given that this contains "adb" and "fastboot": http://developer.android.com/sdk/index.html
  2. In the folder that is created on the laptop's ~/Desktop (or location where the SDK is downloaded), mine was called android-sdk-linux, you will need to execute the installation with "$./android"
    1. Note: This will move/put the "adb" and "fastboot" tools into a different folder titled "platform_tools" (as noted by a little text file that will appear after executing the android file). The sites I have referenced mistakenly refer (perhaps b/c they are old?) to the "tools" folder, which is incorrect and will not work when actually ROM-flashing.
  3. In the virtual machine from where the Android tree was built, the product of the Android Crespo build process will need to be located. The files that are required for manual flashing to the Nexus_S are: system.img, boot.img, and recovery.img
    1. The required files are located in the following directory within the Android tree: ~/out/target/product/crespo
  4. To create an information channel that links the virtual machine to the outside world, since USB ports are not an option and at this time rDesktop-VRDP did not allow the VM within VirtualBox to actually recognize and access the USB ports of a remote computer that connects to it, I chose to use DropBox (https://www.dropbox.com/) and set up an account with a link in my Windows 7 machine and a link in the Ubuntu 10.04 virtual machine (the Ubuntu flavor can be found at: https://www.dropbox.com/install?os=lnx)
    1. If properly set up, the developer can now share files from the Ubuntu virtual machine where the Android tree exists to the external Windows 7 computer (and vice versa), and this is a fairly simple way to get the image files onto a computer which the developer has access to its USB ports (and can put on a flash drive, etc.)
  5. Back on the netbook/laptop where the SDK was installed, copy the system.img, boot.img, and recovery.img files into the "platform-tools" folder of the SDK (these files essentially need to be in the same folder as "fastboot")
  6. Open up a terminal and "cd" into the "platform-tools" folder, and reboot the Nexus S phone into fastboot mode by pressing and holding the Volume Up button and the Power button at the same time until the bootloader screen comes up
    1. Note: An alternative way to enter fastboot mode is to plug in the phone into the USB of the laptop with the SDK, and while the phone is on, enter into the terminal the command:
      $./adb reboot bootloader // This is an IMPORTANT variation of the command with the "./" to execute "adb" found at:  http://source.android.com/source/building.html, otherwise the command "adb" will not work
  7. In the terminal, enter the command:
    $./fastboot oem unlock 
    1. On the phone, there will be a confirmation screen, select YES with Volume Up and pressing the Power button to wipe the device's old data and unlock the phone's bootloader
  8. It may be wise to make a back-up of the current phone system if it matters to preserve the current build on the phone in case something goes wrong during the ROM-flashing process (refer to: http://wiki.yobi.be/wiki/Android#Restoring_.28most_of.29_factory_ROM_.282.3.3.29_with_fastboot and the other references for a guide on how to do this)
    • Note: One error that I did come across was flashing the wrong image to the wrong partition (such as the system.img to the recovery partition), in that case the phone will display a "Block exceeds <hardware_address>..." and the console/terminal will display a failure to write message, in that case, just make sure to re-enter the flashing command properly and everything should work provided you are flashing an image file to the recovery, system, and boot partitions
  9. Enter into the terminal at this point the following series of commands to manually ROM-flash:
    $./fastboot flash recovery recovery.img // This flashes to the "recovery" partition of the phone the recovery image 
    $./fastboot flash system system.img // This flashes to the "system" partition of the phone the actual system image, note this is a big file, mine was approximately 163 MB, so it will take a little to write 
    $./fastboot flash boot boot.img // This flashes the boot image to the "boot" partition of the phone 
    $./fastboot flash userdata userdata.img // This is another partition to flash on the phone for the GALAXY NEXUS (my initial flashing did not work with just the previous 3) 
    • Note: You should see output something similar to (this was for flashing the system.img):
xxxXXX@xxxXXX-netBook:~/Desktop/android-sdk-linux/platform-tools$ ./fastboot flash system system.img
sending 'system' (167451 KB)...
OKAY [ 30.381s]
writing 'system'...
OKAY [ 21.461s]
finished. total time: 51.843s
  • Finally, once a successful output message is seen for each flashing command, on the phone, with the Volume Down and Power buttons select the "Reboot" option to restart the phone with the new Android Crespo build
    • For Nexus S: The following directions just above apply as written
    • For Galaxy Nexus: You will actually need to select "Start" at the top of the screen (as you scroll through various on/off options)
    • For Motorola Xoom: This is the least intuitive of the booting processes. Beware that after typing in the "adb" bootloader reboot command (as in the directions above), the tablet will actually boot into the bootloader mode. The standard start-up screen with the "Starting Fastboot protocol support" message at the top means you are actually inside the bootloader mode. You can enter the "./fastboot" commands I outline above to flash images to the various system partitions and you will see some progress messages on the actual tablet


Source(s): Alexander G. Ororbia II


Thursday June 21, 2012

  • Finished building the Motorola Xoom image
  • Note: At this point, we now have a system image for each phone type, just need to acquire Xoom and Galaxy Nexus hardware to test those image builds on
  • Began the process of dissecting the Android build process. Ideally, we would like to find all of the pieces that go into making the final system image (are those pieces at least all in the actual product folder?), and then separate out the proprietary driver code
    • First, the Makefile found at the top of the Android build tree merely includes a header that is found in a subdirectory that contains what looks the primary Makefile where the building process actually happens
    • Looks like inside the Makefile of ~/Android_Platform_Dev/build/core directory, at around line 746 (in gEdit), there is the reference to the system image, where the actual image file is built, along with the recovery image (with mention of the boot.img file)

Dissection and Analysis of the MakeFile that defines the Build Process

  • IMPORTANT: At about line 992/993, there is a mention of the actual filesystem (bingo!) that is built, which is the real driver-independent portion of the Android image, see the comment I found below:
# ----------------------------------------------------------------- 
# A zip of the directories that map to the target filesystem.
# This zip can be used to create an OTA package or filesystem image
# as a post-build step.
#
  • Did rudimentary search on OTA and found: http://support.creative.com/kb/ShowArticle.aspx?sid=105672
  • At about line 1049 of the same Makefile found within ~/core, it looks like there is actual build step where the file system is packaged into a ZIP file (in something called /zip_root), and right after it looks like there is the step to install the actual kernel file (?)
  • At about line 1052, there is reference to the components of the "recovery image" file
  • At line 1072, there is reference to the contents of the "boot image" file
  • At line 1095, it looks like a possible reference to a (hidden) directory that lists the contents of the actual system image, as well the OTA package
    • Line 1139, there is mention of something called "fs_config", which most likely means file system configuration
  • Then there is a mention of "device vendor", which I believe has something to do with the actual device drivers (perhaps including the proprietary ones we're trying to circumvent in the actual distribution process)
  • What seems to follow after this is a "test build" stage, then the building of the actual Android applications, the emulator, the Platform Development Kit, the SDK
  • Note: At about line 556 is the first real mention of the actual Android kernel, which from reading the code that precedes that point/line, is actually a "kernel image" that is copied over to necessary directories to facilitate the code building process

More Useful Linux/Ubuntu Commands: Searching

  • This reference site helped to figure out how to conduct more refined searches through the file directory tree, especially useful was the flavor of "find" that found all instances that contained a certain kind of extension (i.e. the argument was *.zip): https://help.ubuntu.com/community/find


Source(s): Alexander G. Ororbia II


Friday June 22, 2012

  • Continued dissecting the build process to locate the Android file system produced at the end of the process
  • The ~/out/target/product/$DEVICE/system folder contains the actual Android file system
    • In here there also exists the ~/vendor folder, which contains some of the device driver code we want to avoid distributing
  • Found interesting source describing Android make file system: http://elinux.org/Android_Build_System


Source(s): Alexander G. Ororbia II


General Plan (Tentative)


Source(s): Alexander G. Ororbia II


Sources to Note


Source(s): Alexander G. Ororbia II


Monday June 25, 2012

  • Explored first of 2 possible custom build paths
  1. Integrate FINS at the top level of the Android build process (run the build process with the appropriate kernel modifications)
  2. Integrate FINS into the final product file system that is generated as a result of running the build process (i.e. into the system folder referred in last Friday's log entry), which may allow for a separation of the proprietary code
    • Note: Found out from Android developer that the device drivers may be allowed to be distributed to other users, just not for commercial purposes, will need to dig through license to validate this


Source(s): Alexander G. Ororbia II


Tuesday June 26, 2012

  • Flashed Galaxy_Nexus image files onto the actual hardware --> successfully runs!
  • Flashed the Motorola_Xoom image files onto the actual tablet hardware --> successfully runs!

Galaxy Nexus and Motorola Xoom: USB Recognition Bug on Ubuntu 10.04

  • Initially, the Ubuntu 10.04 OS will not recognize (at all!) the Galaxy Nexus phone plugged in via USB, so follow the directions at the following source to re-enable the "adb" server installed from the SDK to fully recognize the Galaxy Nexus phone: http://tech.onesto.info/2012/02/13/galaxy-nexus-and-ubuntu-10-04-part-1/
  • For both Galaxy Nexus and Motorola Xoom, I also flashed the userdata.img to the userdata partition of the Galaxy Nexus given that when I first flashed the system, recovery, and boot images the phone would not start up properly (after I did those though everything worked fine)--I also updated my manual flashing documentation to reflect this fix
  • For the Xoom, you will need to go to Settings >> Applications >> Development and select the USB Debugging option for the computer to actually recognize the device


Source(s): Alexander G. Ororbia II


Wednesday June 27, 2012


Source(s): Alexander G. Ororbia II


Thursday June 28, 2012

  • Continued trying to build the actual Android kernel
    • After several attempts at building the wingray kernel for Galaxy Nexus, decided to try a different phone (Nexus S) and will work through that path to rule out possibility it's just the kernel for Galaxy Nexus I am having difficulty downloading from GIT


Source(s): Alexander G. Ororbia II


Friday June 29, 2012

  • Tried the kernel build path for the Nexus S and successfully went through the GIT checkout process
    • Noted the path "include/net/ipv6.h:338" in the console output as place to look for kernel networking files (for later)
  • Managed to not only successfully integrate the manually built stock kernel into a complete Android rebuild, but flashed the new resulting image into the Nexus S and the phone WORKS!!!
    • So now I can build an Android platform with a custom kernel
  • Now need to figure out how to integrate FINS kernel code


Source(s): Alexander G. Ororbia II


Notes on Building the Crespo Stock Kernel

  • Following the directions at https://source.android.com/source/building-kernels.html, there a couple of points that the directions do not mention
    • You must check out the GIT folder (for crespo in this case) into a directory built outside of the main Android tree (independent)
    • The directions mention typing in something to the effect of:
      $ make crespo_defconfig 
      While logical, this is incorrect, because in order to actually successfully build for the the Nexus S GT-I9020T (crespo) you will need to run the command
      $ make herring_defconfig 
      It turns out that the crespo config file was actually retitled "herring" for whatever reason during Android phone development.
    • The "SHA1" you will need for the GIT checkout step is the number (as an example) "6656123" from the following example entry you will find after running "$ git log kernel":
commit 1232ac72d0d66b35997fd06e402a9daa9147cbaa
Author: Simon Wilson <simonwilson@google.com>
Date:   Thu Feb 2 17:01:30 2012 -0800

    new kernel + wifi prebuilt
    
    6656123 ARM: s5pv210: herring: don't disable prox sensor during suspend
    
    Change-Id: I6899d07b14f72c2148d9d4fac66f11c88e42466a


Source(s): Alexander G. Ororbia II


Monday, July 2, 2012

  • Continued messing with stock kernel building to integrate FINS
  • First, had to rebuilt the Galaxy Nexus platform (something got lost in translation from the last time I used the VM, and thus I had to scrap--rather, "make clobber"--the old build and recreate it), so that I can build the maguro stock kernel


Source(s): Alexander G. Ororbia II


Tuesday, July 3, 2012

  • Had to do some finagling to get the Galaxy Nexus kernel--the kernel materials to build with are actually located in the "tuna" device folder, not "maguro" as one would expect
  • Note: The actual kernel image for maguro goes into the "tuna" folder, as the "device.mk" within the maguro folder inherits from the "tuna.mk" file
  • Information on checking the kernel from an Android developer source I contacted:
Incremental builds are extremely fast when only changing the kernel
binary: literally, the kernel is concatenated with the ramdisk to
create boot.img...double-check that the kernel gets handled: "touch
device/samsung/tuna/kernel ; make" and check the log. If it says
"Nothing to be done for 'droid'", you've got a problem. If it rebuilds
boot.img, you're fine.


Source(s): Alexander G. Ororbia II


Wednesday, July 4, 2021

  • Happy Fourth of July!!


Source(s): Alexander G. Ororbia II


Thursday, July 5, 2012

  • Worked to build the Motorola Xoom kernel
    • When inserting the kernel into the Xoom build process, had to do a complete rebuild (hence the extended duration for this particular build and was unable to make use of the CCACHE optimization)
  • Tested the Xoom and Galaxy Nexus custom kernels on phones
  • Test WiFi, GPS, graphics on all phones to test kernel functionality
  • Note: Useful resource for understanding/dissecting the Linux kernel: http://lxr.linux.no/#linux+v3.4.4/


Source(s): Alexander G. Ororbia II


Friday, July 6, 2012

  • Continued phone testing
  • Began figuring out how to build FINS kernel code


Source(s): Alexander G. Ororbia II


Monday, July 9, 2012

  • Worked on building FINS code
  • Notes:
    • After downloading the libconfig source, run "$./configure" then "$ make"
  • Modified the Android source kernel to accept FINS registration in the address families section of "socket.h"
  • Need to enable "CONFIG_MODULE_FORCE_UNLOAD" in the Android kernel config file, and "'CONCURRENCY_LEVEL=3" when compiling kernel


Source(s): Alexander G. Ororbia II


Tuesday, July 10, 2012

  • Finished building the modified kernel
  • Ran the Android build process to get the final "system.img" that will contain the modified kernel (for FINS), and now have a system image with the FINS-configured kernel
  • Need to run the FINS build process against the Android kernel source materials to get the Android-enabled kernel module "Wedge"
  • Basic Plan:
    • Now that I have the system image with the FINS-configured kernel, I need to build the "wedge" kernel module
    • This means editing the current Makefile, including "settings.finsmk", perhaps building some output compiled file (like Major's shared libaries in user space) and flashing that onto the phone
    • Then the userspace FINS-core will go onto the phone and in theory the whole FINS system should work for the Moto. Xoom


Source(s): Alexander G. Ororbia II


Wednesday, July 11, 2012

  • Learned about building/inserting kernel modules


Source(s): Alexander G. Ororbia II


Thursday, July 12, 2012

  • Tried building a test kernel module


Source(s): Alexander G. Ororbia II


Building a Kernel Module

  1. Created a simple directory "testMod" on my system's Desktop, and created a C file "hello-1.c" with the code from the second online source
  2. Created "Makefile" that contained the relevant GNU make code for building the "hello-1.ko" module (code example found in second online source), "$ modinfo <kernelModName>.ko" is useful for identifying a built kernel module
  3. Ran the command "$ insmod ./hello-1.ko" to insert the kernel module into the actual base kernel
  4. Can run the command "$ cat proc/modules" to see that the custom module is "Live" and added to the base kernel


Source(s): Alexander G. Ororbia II


General Plan

  • Edit the Makefile that controls the construction of the FINS wedge
    • Will perform the following proposed code operation:
-	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
+	make -C /home/bucknell/wingray/tegra M=($PWD) modules

-	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
+	make -C /home/bucknell/wingray/tegra M=($PWD) clean


Source(s): Alexander G. Ororbia II


Questions that Need Answered

  • What does the "insmod" command actually do? Does it put the ".ko" module somewhere? Where?
  • If I can get the FINS Makefile to build the "wedge" module against the appropriate Android source code, will the process yield a usable ".ko" file? Does the Android phone have a "insmod" command that I can enter into the ADB command line? Or do I have to somehow build the wedge module along with the kernel?


Source(s): Alexander G. Ororbia II


Friday, July 13, 2012

  • Attempted a build-process for the FINS kernel wedge
    • SUCCESS: Finally build the "wedge.ko" file needed with appropriate Makefile edits, still need to test this kernel module combined with the kernel image on an actual phone, and will ultimately need to connect these pieces to Major's userspace FINS piece
  • Useful Tip: Make sure you have run the environment setup commands for the Android build process, including the "lunch" command or else you will get the "eabi" command is missing error


Source(s): Alexander G. Ororbia II


Plan for Monday

  • Retest the stock kernel currently loaded on Motorola Xoom, to rule out any possible errors due to mis-flash of stock kernel
  • Upload/flash modified-FINS kernel along with the custom FINS "wedge" into the Xoom and test for basic functionality
  • Integrate userspace-FINS into Xoom and do a final test-run
    • IF success, then we have a working trial product and can begin testing on Nexus S and Galaxy Nexus


Source(s): Alexander G. Ororbia II


Monday, July 14, 2012

  • Worked on flashing the new kernel module
  • In testing Xoom, noticed that GPS did not work, but WiFi does


Source(s): Alexander G. Ororbia II


Xoom Malfunction

  • Just simply uploaded FINS-configured kernel but phone has entered a pathetic infinite loop and keeps crashing meaning that the kernel modification is too much for the silly phone to handle, so much for testing the FINS "wedge" module I built


Source(s): Alexander G. Ororbia II


Tuesday, July 17, 2012

  • Worked on trying to get the Xoom to work, but phone will not work with the FINS-modded kernel
    • Tried uploading old kernel image and it works, so it really is the FINS modification at "socket.h" that creates the error
  • Broke the Nexus S machine as FINS code would not cooperate with current kernel code, and had syncing issues with the Android repo/git
  • Ran the FINS-configured/modified build for Galaxy Nexus and successfully produced a custom system image (with modded kernel) as well as getting the FINS build process to produce the kernel module I wanted
    • Will test tomorrow


Source(s): Alexander G. Ororbia II


Wednesday, July 18, 2012


Source(s): Alexander G. Ororbia II


Thursday, July 19, 2012


Source(s): Alexander G. Ororbia II


The Android Boot Process Dissected

  1. Execute Boot ROM code (CPU hardwired), which detects the boot media using a system register-->determines where first stage of bootloader is
  2. boot ROM will load first stage of bootloader to internal RAM, boot ROM code jumps and the rest of execution continues within the bootloader
  3. In the bootloader (special program separate from Linux kernel used to set up initial memory and load kernel into RAM):
    1. Detect and set up external RAM
    2. First-stage bootloader loads in main bootloader into external RAM
    3. Main bootloader sets up file systems, additional memory, network support, loading code for modem CPU, setting up low-level memory protections and security
    4. Main bootloader looks for Linux kernel to boot from boot media and place it into RAM and put some boot parameters into memory for the kernel to read at start-up
    5. Bootloader decompresses and jumps to the Linux kernel, kernel takes system over
  4. Kernel sets up everything needed for system to run: initialize interrupt controllers, set up memory protections, caches as well as the system scheduling:
  5. Initilize memory management units and caches so system can use virtual memory and launch user-space processes
  6. Kernel looks at root file system for the "init process" (inside system/core/init in the Android build tree) and launches it as the first user space process
  7. All other processes in the system will launch from the init process (or one of its children processes):
    1. Init process looks for "init.rc" which is a script that contains info on the system services, the phone's file system, etc. --> this init.rc is placed in "system/core/rootdir" of the Android build tree ====> the init.rc is where things at the "native" level are being started up
    2. The init process parses the init.rc script and launches the system service processes
  8. The init process then launches the "Zygote" which will initialize the Dalvik Virtual Machine upon initialization
  9. The "system server", a java component, will be the first thing to run on the system and starts services such as the telephony manager and bluetooth (each service's start-up is written in the system server's "run method"). (Source code: frameworks/base/services/java/com/android/server/SystemServer.java)
  10. System boot completed, where the system server broadcasts the "action": ACTION_BOOT_COMPLETED


Source(s): Alexander G. Ororbia II


Friday, July 20, 2012


Source(s): Alexander G. Ororbia II


Things that DO NOT work in probing the phone for kernel messages

  • Flashing back an old system image that works, running "$./adb logcat", then rebooting the phone the phone in the hopes that logcat will still be running now that it knows the device to talk to


Source(s): Alexander G. Ororbia II


Possible Options

  • These are various paths to take for solving the kernel problem


Source(s): Alexander G. Ororbia II


CWM Wipe


Source(s): Alexander G. Ororbia II


Bootchart

  • Download this program, requires configuring the phone and rebuilding and flashing to see what happens, some modifying of "init.rc"


Source(s): Alexander G. Ororbia II


PandaBoard


Source(s): Alexander G. Ororbia II


Monday, July 23, 2012


Source(s): Alexander G. Ororbia II


Order of steps in init.tuna.rc:

  • Found within "~/device/samsung/tuna"
  1. Sets up phone's SD card for "External storage"
  2. Does a remapping of the SD card
    1. It is here that:
       mkdir /data/misc/wifi 0770 wifi wifi 
       mkdir /data/misc/wifi/sockets 0770 wifi wifi 
  3. Calibrates the camera
  4. Sets up LTE or Long Term Evolution wireless communication for mobile phone data, such as setting up the "radio system":
     chown radio system /sys/bus/i2c/drivers/fsa9480/4-0025/switch 
  5. It says at this point "on boot", but it mounts a debugging file system (?) for the kernel
  6. Set screen's off state maximum fequency
  7. Sets up the CPU "governor (boosts clockspeed set by user)
  8. Suspend "root hubs" (?)
  9. Mounts file systems like ext4
  10. Messes with various devices such the Memory Technology Device and i2c-2 as well as various drivers (Tiler, ION), as well as mess with various permissions (using chown and chmod commands)
  11. Sets up High-Bandwith Digital Content Protection, Near Field Communication (device syncing, data transactions), bluetooth permissions
    1. http://www.techhog.com/what-does-nfc-stand-for-and-what-does-it-do/
  12. Sets up the phone's backlight and LED's
  13. Set up phone GPS
  14. Sets various modes (i.e. "ril control auto-suspend", off-mode, power-control
  15. Sets up fROM (for camera?), attachs HCI (?), pvrsrvinit (for locking? such as spin-locking?)
  16. Sets up cache, userdata file systems
  17. Sets up a "tf_daemon", for networking (?) and smc_pa_wvdrm
  18. Creates a virtual SD card
  19. Sets up *wpa_supplicant*, which is for WPA, WPA2 and older wireless LAN security protocols, ultimately switches to user wifi, sets up an INET socket (?)
    1. http://en.wikipedia.org/wiki/Wpa_supplicant
  20. Sets up dhcpcd_wland0, dhcpcd_p2p, dhcpcd_bnep0, iprenew_wlan0, iprenew_p2p, iprenew_bnep0
  21. Of note: It mentions at this point a "bug report" (perhaps this can be useful to debug?)
  22. Sets up battery charge


Source(s): Alexander G. Ororbia II


Tuesday, July 24, 2012

  • Continued to dissect/understand "init.tuna.rc"


Source(s): Alexander G. Ororbia II


Solution Attempt #1

  • Attempted to debug via simple computer science tricks, i.e. print statement debugging via the "echo" command
  • Inserted various "checkpoints" throughout both "init.rc" and "init.tuna.rc" and had these echo statements route out String output to a "boot_log.txt" file
  • Result = Failure, same boot-loop behavior observed, no new information


Source(s): Alexander G. Ororbia II


Solution Attempt #2

  • Commented out the following block of code within the "init.tuna.rc":
#DECONSTRUCTION #1:  Removing the WPA_SUPPLICANT
#service wpa_supplicant /system/bin/wpa_supplicant \
#	-Dnl80211 -iwlan0 -puse_p2p_group_interface=1 -e/data/misc/wifi/entropy.bin
	#   we will start as root and wpa_supplicant will switch to user wifi
	#   after setting up the capabilities required for WEXT
	#   user wifi
	#   group wifi inet keystore
#	class main
#	socket wpa_wlan0 dgram 660 wifi wifi
#	disabled
#	oneshot
  • Result = Failure, same boot-loop behavior, no new information


Source(s): Alexander G. Ororbia II


Solution Attempt #4

  • Comment out EVERYTHING inside "init.tuna.rc"
  • Result: Failure, same boot-loop behavior, no new information


Source(s): Alexander G. Ororbia II


Next solution attempts

  • Try again a FINS-configured rebuild for the Nexus S
  • Comment out the lines within "init.rc" itself in addition to "init.tuna.rc"
  • Find a different lower-level stage of bootloader to deconstruct and create different behavior


Source(s): Alexander G. Ororbia II


Useful Linux Shell Commands

$ file <filename> // Returns what type of file or executable or script something is


Source(s): Alexander G. Ororbia II


Wednesday, June 25, 2012

  • Possible debugging ideas: run the system image on the Android emulator and see if it produces some sort of boot-logging system, try Nexus S, modify the Android-Linux kernel to produce some messages to at least verify it makes it that far in boot process

Thursday, July 26, 2012

  • Got the Android emulator to work with the FINS-modified kernel, however, something is not quite right, as the system boots not only to a stable state, but allows internet browsing (should not be possible)
  • Strange code snippet that means something isn't quite right:
<4>goldfish_new_pdev goldfish_interrupt_controller at ff000000 irq -1
<4>goldfish_new_pdev goldfish_device_bus at ff001000 irq 1
<4>goldfish_new_pdev goldfish_timer at ff003000 irq 3
<4>goldfish_new_pdev goldfish_rtc at ff01000
  • Answer: The above reflects that I am using the emulator's kernel, goldfish, which means I am not running the FINS-configured kernel


Source(s): Alexander G. Ororbia II


Friday, July 27, 2012

  • Investigated how and actually modified/rebuilt the "goldfish" emulator kernel and ran the emulator to simulate a FINS-configured "socket.h" boot-loop issue I have been experiencing on hardware
    • It appears the actual "default" kernel the emulator wants to use is found at: kernel.path = /home/bucknell/Android_Platform_Dev/prebuilts/qemu-kernel/arm/kernel-qemu-armv7
  • Tried tricking the Android emulator to use my own "kernel-qemu-armv7", overriding older default one, but may need to a "rebuild" with the script there to make use of the vmLinux-qemu-armv7
  • Success: Phone boots, no internet as predicted


Source(s): Alexander G. Ororbia II


Monday, July 30, 2012

  • Got the emulator to work with the FINS-configured goldfish kernel last Friday -- phone boots to stable state, internet does not work (as desired, given there are technically no protocols), and phone appears to boot off (however, it seems to freeze in the boot-off process after the log registers that the phone system has successfully halted--perhaps a bug in the emulator)
    • However, it appears you cannot use the ADB daemon b/c it requires INET? Even though the phone boots successfully, the adb server registers the phone as "offline" and the phone itself states in the kernel log that it cannot connect to the ADB server
    • Need to program the phones "init.rc" to install/insert the wedge module
  • Tests:
    • Run the emulator with a maguro/tuna kernel, FINS-configured
      • Behavior: Emulator doesn't even make it to the "booting the kernel command line", and hence doesn't even reach the first boot screen ("Android")
    • Boot the phone with a goldfish kernel, FINS-configured
  • Tested the emulator version of FINS
    • Test the kernel "wedge" module
    • Test the userspace FINS code


Source(s): Alexander G. Ororbia II


Plan for Tuesday July 30, 2012

  • In light of a bunch of errors and problems that crept up in the Galaxy Nexus build process, I migrated to Nexus S and will perform the following:
    • Rebuild the crespo system image with FINS-configured kernel and try flashing the phone (currently rebuilding at moment of this log entry)
    • Rebuild the "full-eng" build for the emulator and try running that with FINS (and see if it works like Galaxy Nexus)
    • Rebuild the crespo system image with FINS-config kernel but using the emulator "goldfish" kernel in one attempt to trick the phone to work like everything does so well on the emulator

Tuesday, July 31, 2012


Source(s): Alexander G. Ororbia II


Differences between Goldfish and Crespo

  • Within "~/include/linux/socket.h", the Crespo kernel contains:
...
#define AF_IEEE802154 36 /* IEEE802154 sockets */
#define AF_CAIF       37 /* CAIF sockets */
#define AF_ALG        38 /* Algorithm sockets */
...
//Also there are the corresponding PF_<name> symbols for these AF protocol families-to-register
  • Within "init.goldfish.rc", there are a few things different about phone set-up compared to "init.herring.rc":
# start essential services
   start qemud
   start goldfish-logcat
   start goldfish-setup
  • Some ideas to try in modifying the Nexus S init script: try activating logcat early like the emulator does, try find a different "echo" command to create a signal to at least prove the phone makes it to the initialization process


Source(s): Alexander G. Ororbia II


Tomorrow

  • Want to test the emulator one more time, but with a faked kernel "crespo-modified disguised as goldfish"
  • Will need to rebuild a working, normal version of Crespo and try it out on phone
  • Need to package the VM's I do have, repo sync them to correct them, and write some directions on how to use them


Source(s): Alexander G. Ororbia II


Wednesday, August 1, 2012

  • Worked on VM packaging and documentation
    • Wrote the first draft of the README.txt (shown in the last entry of this wiki)
    • Cleaned up the Xoom_platform, ready now for final packaging/exporting (IP = 134.82.9.63:3389)
    • Cleaned up the Nexus_S_platform (Nexus_S_July31 snapshot), ready now for final packaging/exporting (IP = )
    • Cleaned up the Galaxy_Nexus_platform (Galaxy_Nexus_plat_June17_2012 snapshot), ready now for final packaging/exporting (IP = )
  • Worked on the kernel problem, trying to ascertain differences between Goldfish and Crespo


Source(s): Alexander G. Ororbia II


Instructions/Methods for Android Platform Development and FINS

  • Note: A more specific copy of the following directions can be found in each packaged Virtual Machine.
  • Terminology:
    • <device_project_name> refers to the appropriate Android platform system name. Use the following key to figure out which name applies to your platform:
       Nexus S = "crespo"     Galaxy Nexus = "maguro"     Motorola Xoom = "tegra"
    • <kernel_name> refers to the appropriate Linux kernel needed for a specific platform, particularly so that you can build the correct kernel configuration file. Use the following key to figure exactly which kernel applies to your platform so that you can also select the correct config file:
Nexus S = you will need to use herring"
Galaxy Nexus = you will need to use "tuna"
Motorola Xoom = you will need to use "stingray" 
####################################### Platform Building Instructions: Android and FINS #########################################
##############################################  By: Alexander G. Ororbia II   ####################################################

Note:  I configured the Android platform environments to make use of "DropBox", a free online utility that allowed me to create a connection from any host computer to the actual virtual machine and share/transport important data files given I was connecting to these virtual machines via Remote Desktop Clients (this is the result of the limitations of VirtualBox, where the virtual machines created from this software cannot make use of the client machine's USB ports, cutting off use of flash-drives, if the virtual machine exists outside of the client, such as on a server computer).

################################################### Building the Android Kernel ###################################################

NOTE:  Unless you are interested in modifying the Android kernel for the platform you are working on (especially for FINS), a working, pre-made Android kernel (non-FINS) has already been placed into the appropriate directory for the build process to work.

1)  Before navigating into the kernel build tree, "cd" into the ~/Android_Platform_Development folder and run the following commands (in order):

$ . build/envsetup.sh
$ lunch full_<device_project_name>-eng

This step ensures that everything is pointed correctly to avoid the build process from confusing itself.  If you do not do this, you will get various error messages, including how the tree cannot find the "arm-eabi-" compiler.
2)  Make sure you set your environmental variables as follows:

ARCH = arm
SUBARCH = arm
CROSS_COMPILE = arm-eabi-

2.1)  FINS MODIFICATION:  You can find within the kernel source file ~/<device_project_name>/<kernel_project_name>/include/linux/socket.h commented out FINS code.  Just simply remove the appropriate pre-FINS code and uncomment the FINS lines to get the proper FINS configuration for the Android kernel.  Please consult the following site if needed:  http://finsframework.org/mediawiki/index.php/Documentation_-_FINS_v0.9.0#Modified_Kernel

3) Navigate into the specific project folder for each kernel.  For Nexus S, this will be ~/crespo/samsung.  For Galaxy Nexus, this will be ~/tuna/omap.  For Motorola Xoom, this will be ~/wingray/tegra.

3.1) Within the kernel project folder, run the following set of commands:

$ make <kernel_name>_defconfig  # This creates the kernel configuration file for the specified kernel
$ make -j3 # This runs the make process to build the final kernel image (to be placed within the ~/Android_Platform_Development tree)

3.2)  It is within here that you can make modifications to the kernel (the directory structure is that of the standard Linux kernel source code tree)
4) You can now extract the resulting kernel image file from ~/arch/arm/boot/zImage.  Rename the file to "kernel"
 and place within the ~/Android_Platform_Development/device/<companyName>/<phone_kernel_name> folder, overwriting the current kernel within there

############################################### Building the Android Platform ###################################################

NOTE:  All the relevant optimizations have been built into these packaged Android trees, so future rebuilds should take less time than the initial one (unless something is messed up that the tree can no longer build properly, then a reset with "$ make clobber" will be needed).

1)  Configure the build environment by running the following set of commands (in order):

$ . build/envsetup.sh
$ lunch full_<device_project_name>-eng # the "-eng" gives the build full debugging capability

2)  Run the following command to actually build the Android platform:

$ make -j8 # the "-jN" flag optimizes the build process by allowing it to divide into threads when appropriate
# alternatively you can run "$ make ARCH=arm -j8" to ensure the correct architecture for the Android phone is selected

3)  Navigate to the ~/out/target/product/<device_project_name>
4)  The files produced from the build process required to flash a phone are:  system.img, boot.img, recovery.img, and userdata.img (to completely flash the important partitions of the phone hardware)

############################################### ROM-Flashing the Android phone ###################################################

There are two working environments needed for a phone flash.  One will be the Virtual Machine (built with the VirtualBox software) where the Android Build Tree exists (the one used in the set of directions labelled "Building the Android Platform) and the other will be a different laptop or computer where the actual phone hardware will be plugged into via USB and where the ROM-flashing commands will be entered.

Note:  This is how I set up my environment for a successful phone flash.  Make sure you have the Android SDK and a comparable environment to Ubuntu 10.04 for these directions to apply.  Refer to my wiki entry, Wednesday June 20, 2012, for a few more specific details and site link references, such as configuring a DropBox channel if desired.  DropBox was used as my means of transporting the image files from the VM (where the Android Build tree existed) to my host computer (given my VM existed on a server computer and my computer was connecting to the server via RDP).  You can use DropBox by creating a connection within the VM and in the host computer you are running the VM by downloading and following the directions on the DropBox site:  https://www.dropbox.com/.  Alternatively, you can try to configure your virtual machine (since it exists and is running directly on your host computer) by playing with the VirtualBox software to allow the VM to access the host computer's USB ports.  Consult http://www.virtualbox.org/manual/ch03.html#idp13237504 for the proper approach in configuring this option.

1) Make sure you have a netbook/laptop (as I did) or a computer with USB access loaded with an Ubuntu 10.04 OS
2) Find and download the Linux version of the Android SDK if you do not already have it installed on the system, and via the Android SDK Manager select "platform_tools", given that this contains "adb" and "fastboot" (this is critical for successful ROM-flashing):  http://developer.android.com/sdk/index.html
2.1) The version of the Android SDK downloaded when these directions were created was:  android-sdk_r20.0.1-linux.tgz
3) In the folder that is created on the laptop's ~/Desktop (or location where the SDK is downloaded), mine was called "android-sdk-linux", you will need to execute the installation with "$./android"
3.1) Note:  This will move the "adb" and "fastboot" tools into a different folder titled "platform_tools" (as noted by a little text file that will appear after executing the android script file).  The sites I have referenced mistakenly refer (perhaps b/c they are old?) to the "tools" folder, which is incorrect and will not work when actually try to ROM-flash.
4) In the virtual machine from where the Android tree was built, the product of the Android build process will need to be located. The files that are required:  system.img, boot.img, recovery.img, and userdata.img
4.1) The required files are located in the following directory within the Android tree:  ~/Android_Development_Platform/out/target/product/<device_project_name>
4.2) Copy these image files into an external flashdrive
5) Back on the netbook/laptop where the SDK was installed, copy the system.img, boot.img, and recovery.img files from the flashdrive into the "platform-tools" folder of the SDK (these files essentially need to be in the same folder as the fastboot binary)
6) Open up a terminal and "cd" into the "platform-tools" folder, and reboot the Android phone into fastboot mode by following the appropriate set of directions, found here:  http://source.android.com/source/building-devices.html
6.1) Note: An alternative way to enter fastboot mode is to plug in the phone into the USB of the laptop with the SDK, and while the phone is on, enter into the terminal the command:  
$./adb reboot bootloader  # This is an IMPORTANT variation of the command with the "./" to execute "adb", otherwise the command "adb" will not work
6) In the terminal, enter the command:  

$./fastboot oem unlock

6.1) On the phone, there will be a confirmation screen, select YES with Volume Up and pressing the Power button to wipe the device's old data and unlock the phone's bootloader
7) It may be wise to make a back-up of the current phone system if it matters to preserve the current build on the phone in case something goes wrong during the ROM-flashing process (refer to:  http://wiki.yobi.be/wiki/Android#Restoring_.28most_of.29_factory_ROM_.282.3.3.29_with_fastboot and the other references for a guide on how to do this)
7.1) '''Note:''' One error that I did come across was flashing the wrong image to the wrong partition (such as the system.img to the recovery partition), in that case the phone will display a "Block exceeds <hardware_address>..." and the console/terminal will display a failure to write message, in that case, just make sure to re-enter the flashing command properly and everything should work provided you are flashing an image file to the recovery, system, and boot partitions, as well as userdata (just to make sure you wipe clean the old user data, although this is usually automatically done, except for Galaxy Nexus)
8) Enter into the terminal at this point the following series of commands to manually ROM-flash: 

$./fastboot flash recovery recovery.img # Flashes to the "recovery" partition of the phone the recovery image
$./fastboot flash system system.img # Flashes to the "system" partition of the phone the actual system image, note this is a big file, mine was approximately 163 MB, so it will take a little to write
$./fastboot flash boot boot.img # Flashes the boot image to the "boot" partition of the phone
$./fastboot flash userdata userdata.img # This is another partition to flash on the phone especially for the GALAXY NEXUS

8.1)  Note: You should see output something similar to (the following sample was for flashing the system.img): 

xxxXXX@xxxXXX-netBook:~/Desktop/android-sdk-linux/platform-tools$ ./fastboot flash system system.img
sending 'system' (167451 KB)...
OKAY [ 30.381s]
writing 'system'...
OKAY [ 21.461s]
finished. total time: 51.843s

8.2)  After successfully flashing, you will want to run the following command to re-lock the phone:

$./fastboot oem lock

9) Finally, once a successful output message is seen for each flashing command, on the phone, with the Volume Down and Power buttons select the "Reboot" option to restart the phone with the new Android build

Specifics for ROM-flashing to each of the 3 Supported Phone types:

1) For Nexus S:  Follow directions above as written.  To reboot the phone, make sure to simply select reboot at the bootloader menu screen when you finished.
2) For Galaxy Nexus:  When it is time to reboot, you will actually need to select "Start" at the top of the screen (as you scroll through various on/off options).
3) For Motorola Xoom: This is the least intuitive of the three booting processes.  Beware that after typing in the "$ adb bootloader-reboot" command (as in the directions above), the tablet will actually boot into the bootloader mode even though it may not look like it.  The standard start-up screen with the "Starting Fastboot protocol support" message at the top means you are actually inside the bootloader mode (there are no other indicators you have made it into bootloader mode).  You can enter the "./fastboot" commands outlined above to flash images to the various system partitions and you will see some progress messages on the actual tablet as you do.

############################################ Building FINS kernel module: The Wedge ###############################################

Note:  Make sure the appropriate FINS MODIFICATION step was followed in the "Building the Android kernel" direction set before building the FINS Wedge against the Android-Linux kernel source code.

1)  Inside the packaged Android platform VM, you can find a copy of the FINS-Framework project folder (~/FINS-Framework).  Navigate to the "wedge" sub-directory where you can find the core C files that compose the FINS Wedge, which is the critical link between FINS Userspace and the FINS-configured kernel (you may also find some prebuilt kernel module files for the wedge, however you can clean these by running "$ make clean".
2) Make sure you have already run the Android environment build commands within ~/Android_Platform_Development as you did at the start of the "Building the Android Kernel" and "Building the Android Platform" direction sets (i.e. "$ . build/envsetup.sh" and "$ lunch <device_name>-eng") before you try building the FINS Wedge
3) To build the FINS Wedge kernel module from scratch please simply run the following command:

$ make

3.1)  The modified Makefile can be found in the same directory, but at the bottom of this wiki you can find a copy of the exact Makefile code I used to compile the kernel wedge.  This Makefile ensures that the FINS Wedge is built against Android kernel source files and not the host Linux machine's source code modules (They have already been tailored to the specific Android VM you are using, so the code will build against the correct Android-Linux kernel source code).

################################################ Running the Android Phone Emulator ###############################################

1) Change into the ~/Android_Platform_Development directory and make sure you have already run the environment build commands that you did at the start of the "Building the Android Kernel" and "Building the Android Platform" direction sets (i.e. "$ . build/envsetup.sh" and "$ lunch <device_name>-eng")
2) Type in the following command:

$ emulator

3) You should now see a pop-up dialog with the Android emulator booting (the "Android" splash-screen should appear on the digital display at this point)

FINS-Android Makefile: My Modification

ns.mk contains the compiler and linker options for each target platform
#include ../settings.finsmk

#Name of the module
PROJECT_NAME = wedge

#CFLAGS += $(WEDGE_INC)
#OBJS = FINS_stack_wedge.o

#This is an autogenerated list of includes used in this project
#INCLUDES = $(shell ls $(subst -I,, $(CAPTURER_INC)) | grep \\.h)

obj-m += FINS_stack_wedge.o			# build type hardcoded to module

all:
#	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
	make -C /home/bucknell/wingray/tegra M=$(PWD) modules
clean:
#	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
	make -C /home/bucknell/wingray/tegra M=$(PWD) clean

#.PHONY:all
#all:userspace_tests $(PROJECT_NAME)
#	@echo "$(PROJECT_NAME) is compiled\n"

#userspace_tests:
#	@cd Userspace_tests; make all

#$(PROJECT_NAME):
#	@make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

#.PHONY:clean
#clean:
#	@cd Userspace_tests; make clean
#	@make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
		
#### TARGETS #####
#%.o:%.c $(INCLUDES) 
#	@$(CC) $(CFLAGS) -c $<


Source(s): Alexander G. Ororbia II


Thursday, August 2, 2012

  • Finished packaging/documentation
  • Built a Abdallah an Android VM equipped with emulator to continue his thread of FINS work
  • Began plan to solve kernel issue: Program the init.rc scrip to install the FINS wedge kernel module and see what behavior ensues


Source(s): Alexander G. Ororbia II


Tuesday, August 14, 2012

  • Patched up documentation
  • Exported development virtual machines with instructions


Source(s): Alexander G. Ororbia II

Personal tools