ubuntu14.04 Android build environment in Debian Jessie

While attempting to build up my 1 year old android beagleboard-x15 image back again to verify functionality, well.. I had left ubuntu behind and had moved on to debian. Unfortunately, I dont seem to have the patience to get debian android build stable... so chroot of ubuntu 14.04 and build of android in that environment.

sudo apt-get install schroot dchroot debootstrap
sudo vim /etc/schroot/schroot.conf
[android]
description=Ubuntu Trusty Android build env
location=/opt/android-build/
priority=3
users=USER #update with your user
groups=GROUP #update with your user group
root-groups=root


sudo mkdir -p /opt/android-build
sudo debootstrap --arch amd64 trusty /opt/android-build  http://archive.ubuntu.com/ubuntu/

sudo vim /opt/android-build/etc/apt/sources.list
###### Ubuntu Main Repos
deb http://us.archive.ubuntu.com/ubuntu/ trusty main restricted universe multiverse 

###### Ubuntu Update Repos
deb http://us.archive.ubuntu.com/ubuntu/ trusty-security main restricted universe multiverse 
deb http://us.archive.ubuntu.com/ubuntu/ trusty-updates main restricted universe multiverse 
deb http://us.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse 


sudo vim /etc/fstab
 proc /opt/android-build/proc proc defaults 0 0
 /dev/ /opt/android-build/dev none rbind 0 0
 sysfs /opt/android-build/sys sysfs defaults 0 0


sudo cp /etc/resolv.conf /opt/android-build/etc/
sudo mount -a

sudo cp /etc/sudoers /opt/android-build/etc/
sudo cp /etc/passwd /opt/android-build/etc/
sudo sed 's/\([^:]*\):[^:]*:/\1:*:/' /etc/shadow | sudo tee /opt/android-build/etc/shadow
sudo cp /etc/group /opt/android-build/etc/
sudo cp /etc/hosts /opt/android-build/etc/
sudo mkdir /opt/android-build/home/$(USER); sudo chown $(USER).$(USER)  /opt/android-build/home/$(USER)

sudo chroot /opt/android-build/
 apt-get update
 apt-get --no-install-recommends install wget debconf devscripts gnupg vim nano  ctags cscope gcc-arm-linux-gnueabi bc linux-generic #For package-building
 apt-get update  #clean the gpg error message
 apt-get install locales dialog  #If you don't talk en_US
 locale-gen en_US.UTF-8  # or your preferred locale
 tzselect; TZ='Continent/Country'; export TZ  #Configure and use our local time instead of UTC; save in .profile
 dpkg --add-architecture i386
 wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -;sudo rm -rvf /var/lib/apt/lists/* -vf;sudo apt-get update && sudo apt-get dist-upgrade -y && sudo apt-get autoclean -y && sudo apt-get autoremove -y && sudo apt-get --purge --reinstall -y install flashplugin-installer;sudo apt-get update;dpkg --list | grep linux-image|grep -v 'Generic'|head --lines=-3|sed -e 's/\s\s*/ /g'|grep -v `uname -r`|cut -d ' ' -f2|xargs sudo apt-get purge -y
 apt-get purge openjdk-\* icedtea-\* icedtea6-\* 
 apt-get install git ccache automake lzop bison gperf build-essential zip curl zlib1g-dev zlib1g-dev:i386 g++-multilib python-networkx libxml2-utils bzip2 libbz2-dev libbz2-1.0 libghc-bzlib-dev squashfs-tools pngcrush schedtool dpkg-dev liblz4-tool make optipng
 apt-get install openjdk-7-jdk
 exit

dchroot -c android -d
 cd ~
 mkdir ~/bin ; curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo && chmod a+x ~/bin/repo


Building for BeagleBoard-X15 (still to be completed)
Lollipop: mkdir ~/android-lollipop-build;cd ~/android-lollipop-build;repo init -u https://github.com/nmenon/aosp-manifest-x.git -b x15-loli-dev
Marshmallow: mkdir ~/android-marshmallow-build;cd ~/android-marshmallow-build;repo init -u https://github.com/nmenon/aosp-manifest-x.git -b x15-marshy-dev

repo sync

Quick and Dirty userspace testing of regulator with virtual consumer

Writing a driver for a new regulator is usually fun, until you need to test the darned thing. Many of the users of the regulator is probably not yet ready in an development environment and need to test cant wait.
I had recently a similar situation and found CONFIG_REGULATOR_VIRTUAL_CONSUMER
You'd probably register and provide and regulator supply, but without a driver using it in a controlled environment (read shell script or so), it is hard to poke holes completely into your driver.

Steps are rather simple.
Assumption - you already have a regulator registered in the system and you are aware of the regulator name - You can also figure out it's name by the following (an example from 3.9-rc8 on Beagle-XM):

# head /sys/class/regulator/*/name
==> /sys/class/regulator/regulator.0/name <==
regulator-dummy
==> /sys/class/regulator/regulator.1/name <==
VDD1
==> /sys/class/regulator/regulator.2/name <==
VDAC
==> /sys/class/regulator/regulator.3/name <==
VPLL2
==> /sys/class/regulator/regulator.4/name <==
VMMC1
==> /sys/class/regulator/regulator.5/name <==
VUSB1V5
==> /sys/class/regulator/regulator.6/name <==
VUSB1V8
==> /sys/class/regulator/regulator.7/name <==
VUSB3V1
==> /sys/class/regulator/regulator.8/name <==
VSIM

Assume for the moment, we'd like to test VSIM. Fastest is often the simplest for testing needs. We introduce an dummy device which virtual-consumer picks up and exposes sysfs nodes- late init is usually an handy place to plug this dummy device injector ;)

char name[] = "VSIM";
struct platform_device_info devinfo = {
 .name = "reg-virt-consumer",
 .id = 0, /* if registering more than a single regulator, increment the ID */
 .data = name,
 .size_data = sizeof(name),
};
platform_device_register_full(&devinfo);

NOTE: do this for every "virtual consumer" you need to add for testing
Bingo, job done. Now you should be able to see the virtual consumer (the .0 matches to the id we give)

/ # ls -al /sys/devices/platform/reg-virt-consumer.0
total 0
drwxr-xr-x    3 root     root             0 Dec 31 20:30 .
drwxr-xr-x   17 root     root             0 Dec 31 20:30 ..
lrwxrwxrwx    1 root     root             0 Dec 31 23:15 driver -> ../../../bus/platform/drivers/reg-virt-consumer
-rw-rw-rw-    1 root     root          4096 Dec 31 23:15 max_microamps
-rw-rw-rw-    1 root     root          4096 Dec 31 20:30 max_microvolts
-rw-rw-rw-    1 root     root          4096 Dec 31 23:15 min_microamps
-rw-rw-rw-    1 root     root          4096 Dec 31 20:30 min_microvolts
-r--r--r--    1 root     root          4096 Dec 31 23:15 modalias
-rw-rw-rw-    1 root     root          4096 Dec 31 23:15 mode
drwxr-xr-x    2 root     root             0 Dec 31 23:15 power
lrwxrwxrwx    1 root     root             0 Dec 31 23:15 subsystem -> ../../../bus/platform
-rw-r--r--    1 root     root          4096 Dec 31 23:15 uevent
/ # 

Here is a quick test:

REG=/sys/class/regulator/regulator.8
CONS=/sys/devices/platform/reg-virt-consumer.0
for V in 1000000 1200000
do
 echo -n "$V">$CONS/min_microvolts
 echo -n "$V">$CONS/max_microvolts
 echo "Tried $V, Voltage =" `cat $REG/microvolts`
done

Now the homework: do this using device tree :)
More info: Documentation/ABI/testing/sysfs-class-regulator and https://www.kernel.org/doc/htmldocs/regulator.html - Happy hacking..
Caveats: posting upstream patches making this standard user-space control for regulators is usually frowned upon.

Linux

*Browser-based circuit simulator boasts a...

Browser-based circuit simulator boasts a mountain of features You can build your schematic in the editor mode, then switch over to the simulator to get data back from the components. In that mode, your cursor becomes a probe, and clicking on different parts of the circuit will return the calculated input and output voltages for that component. But wait, there's more. It's got time and frequency simulation in addition to the voltage simulator. This lets you look at waveforms fed through analog filters, or timing data like in the 555 timer circuit above. http://hackaday.com/2012/03/02/browser-based-circuit-simulator-boasts-a-mountain-of-features/ Getting Started with CircuitLab youtube.com - www.circuitlab.com CircuitLab is a suite of web-based electronics design tools, including the first web-based circuit simulator with the power and ...

Measuring boot voltage on PandaBoard ES - part 1

What am I trying to do?

Pandaboard ES OMAP4460's main voltage rails are vdd_mpu, vdd_core, vdd_iva.

MPU and IVA domains have dependency on Core (obvious since Core drives the common bus on OMAP called the L3 bus). Our intent here is to measure voltages of these rails and ensure they are the right voltage levels and in the right sequence as U-boot SPL comes up.

Stage #1 - knowing what to measure
This is pretty easy on most other boards, but on PandaBoard ES, things are a mite more interesting.  Unlike most other OMAP3 and OMAP4430 boards,  OMAP4460 on Pandaboard ES is powered by 2 PMICs!. A TPS62361 drives it's vdd_mpu rail while TWL6030 supplies the vdd_iva and vdd_core rails.

lets look at each one in detail: (the following figures are excerpts from schematics of PandBoard ES)

As seen in the schematics, TPS62361 is a slightly different beast to deal with. Three paramaters play an important role for the voltage to appear in the inductor at L23.

1.  is "EN" (signal PHO_SYSEN)
2. The internal registers used to select the voltage is selected by VSEL0 and VSEL1 (only VSEL0 is controlled by OMAP over the signal H_GPIO_WK_7) - this basically means that VSEL0 allows the selection of 2 registers - SET0 or SET1 register inside TPS (SET0 default is <1V, which SET1 defaults approx to 1.4ish volt - refer to latest dataasheet for accurate spec).
3. and finally the voltage itself which is send from OMAP to TPS over I2C (SRI2C for OMAP).

This chip is like any other chip - Programming sequence in a nutshell is simple:
ensure that EN pin is active and VSEL0 is set properly, program the voltage and bingo, the voltage appears on L23 inductor. A small point to remember is that EN pin actually is driven by SYSEN line of TWL6030. SYSEN is asserted when OMAP4460's PWRREQ is asserted - so this allows for TPS to hit 0V when OMAP4460's "OFF" mode is achieved. Kinda wicked if you saw this the first time coming from simple OMAP <-> PMIC story..

Now to vdd_iva and vdd_core:

Good news: this side of the story is rather simple :). Since VDD_MPU is now driven by TPS, TWL6030 VCORE1 supplies vdd_Core (VDD_VCORE3 in the schematics) and VCORE2 supplies vdd_IVA (VDD_VCORE2 in the schematics) - without going into much details, it is just programming the voltage register over SRI2C.

Bottom line:
vdd_MPU =  L23
vdd_Core = L14
vdd_IVA = L16

Remember typically the inductors when probed show noisy signal towards PMIC and clean signal towards OMAP (duh.. that is exactly what an inductor is supposed to do in the first place) - so use it to figure out which side of the inductor to solder the wire on..

umm... where are the inductors on the board??
A long story short  download the user manual and look it up. I was told to RTFM after a failed experiment with gerbv and following which I ended up getting access to a windows machine and installing allegro - converting the brd file to search-able PDFs.

Stage #2 - An soldering strategy
Deciding to solder is usually easy, but the hard part is looking at the components. Disclaimer: Am just a code junkie, so many of my personal thoughts on soldering may be outright wrong ;).. Read at your own risk..

If the wire is too thick, e.g. a 22guage on a tiny resistor puts a lot of pressure on the poor little thing and will break off eventually. if too long it picks up all kind of noise distorting the measurements.

Now, I have a DSO Quad (handy little oscilloscope that could be praised in it's own right). Anyways the connectors are standard passive scope connector like + "clumsy me" factor - I always tend to get something caught in power wire or in the scope cable or so and.....

Found some of PCB board headers I had lying around and decided to stick them with super glue to the PCB. This lets me connector jumpers that I can remove + add more wires in the future as I need, once I am done probing, I wont have wires waving in the air looking for the closest ground source either ;) - of course stick it someplace close to a ground point..

[Update: 2012025:1931: David Anders pointed that the entire steps have been simplified here I still think this series is useful as it explains the fundamentals of the same.]

So we hit the next gen

Texas Instruments demos first OMAP 5, Android 4.0-based reference design, promises it in laptops next year (video) -- Engadget

firewall on N900

Grr my first post of this year and I plan to start "I confess: I am a paranoid". what the heck, lets go with it:

I confess, I am a paranoid. I carry around my N900 all the time and thanks to my job, I end up in different continents at times. with my primary SIM connection, international data network tends to around 15$/MB which I don't really feel like paying, so I either choose a local SIM (If I am around for that long that deserves it) OR more likely to use WLAN in the hotel or guest network I am allowed on. I don't like wlan network in general other than the one I personally setup. and hence dont like the thought that my phone's network services are open for all on wlan0 device :(. This triggered my search for something quick and simple firewall. I think of it more or less as a basic password I'd setup on my laptop of a phone unlock code or lock my car when I step out of it - it can be counteracted, but what the heck, some one has to see it worthwhile the effort to do it (and I don't personally think I am worth that effort ;) ). Anyways, back to code..

Maemo wiki(search for the word firewall) unfortunately tells me dubious statement "Maybe not". on a phone data network, I am reasonably sure that the 3G provider really does'nt want to pay for people running nmap on other people's phone - I guess they are pretty serious about it, but unfortunately most wifis contain machines which are already compromised - the users really dont control their PCs anymore.. and my poor phone has to share the world with them as well.. (Disclaimer: I did say I am a paranoid, ok maybe a little bit paranoid).

Since even "ET call home" does'nt really need my phone to run Apache server or an SMTP server, I dont need a complicated firewall setting. I needed something as simple as gufw
yes OR no.

Since I am never the first to look for something, bit of googling later, found this
few customizations for this script I setup the following with the N900 power kernel:
Note: for what ever reasons, N900 default kernel on PR1.3 does'nt come with these modules in /lib/modules/`uname -a` :(

~/bin/fire:

#!/bin/bash

set -x

# Load needed kernel modules

modprobe ipt_MASQUERADE
modprobe ipt_NETMAP
modprobe ipt_REDIRECT
modprobe ip_tables
modprobe ipt_REJECT
modprobe iptable_filter
modprobe iptable_mangle
modprobe iptable_nat


# Clear any existing firewall stuff before we start
# TODO: really not secure thingy- might wanna do REJECT rules before this..
iptables --flush

# As the default policies, drop all incoming traffic but allow all
# outgoing traffic.  This will allow us to make outgoing connections
# from any port, but will only allow incoming connections on the ports
# specified below.

iptables --policy INPUT DROP
iptables --policy OUTPUT ACCEPT

# Allow all incoming traffic if it is coming from the local loopback device
iptables -A INPUT -i lo -j ACCEPT

# Related and established connections: see
#  http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html
#
# Accept all incoming traffic associated with an established
# connection, or a "related" connection
#
# This will automatically handle incoming UDP traffic associated with
# DNS queries, as well as PASSIVE mode FTP (provided the
# ip_conntrack_ftp module is loaded)

iptables -A INPUT -i phonet0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i wlan0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i wmaster0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow connections on selected ports to the firewalled computer:

# Logging: first, eliminate any packets that are going to broadcast
# addresses, since they will overwhelm the log files if there are any
# windows computers on our network. Also, don't log pesky multicast
# packets that we block.

iptables -A INPUT -d 255.255.255.255/0.0.0.255 -j DROP
iptables -A INPUT -d 224.0.0.1 -j DROP

# Log all other blocked packets, and change DROP to REJECT to be
# polite and allow people connecting to a blocked port to receive a
# "connection refused" message instead of timing out after 30 seconds.

#iptables -A INPUT -j LOG
iptables -A INPUT -j REJECT

And the reverse: ~/bin/nofire

#!/bin/bash
set -x

# Clear any existing firewall stuff before we start

iptables --flush

# A dumb set of steps - just being explicit here..
iptables --policy INPUT ACCEPT
iptables --policy OUTPUT ACCEPT

I then added desktop command execution widget to basically use call firewall ON and OFF with a dumb command of /bin/bash -c "/usr/bin/rootsh /home/user/bin/fire" for firewall on and /bin/bash -c "/usr/bin/rootsh /home/user/bin/nofire" for no firewall - activated only if I click on it.

Anyways, as usual, lazy halfbaked though it is, just sharing the goodies - do feel free to improve it and post your own or maybe some real security expert can post a better set of scripts here..

Ofcourse, the only pet peeve I have is this - I, for some reason cannot use my camera with power kernel. mebbe some day will have time to look at all things I want..

[Late realization of searching for N900 ufw on google gave me this]