Friday, April 26, 2013

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.

Tuesday, April 03, 2012

Linux

Saturday, March 03, 2012

*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/


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 ...

Saturday, February 25, 2012

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.]




Friday, January 13, 2012

So we hit the next gen

Thursday, February 03, 2011

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]

Saturday, October 16, 2010

meego kernel on pandaboard?

What exactly is a kernel? at the end of the day, just a collection of patches :).. So yeah, I have a "unique" collection of patches for PandaBoard that I requested MeeGo kernel maintainers to pick up yesterday. Now to wait and see if they actually get accepted. Next steps would be tough:

DSS - omapfb enablement
EHCI - keyboard and mouse

As usual, the patches to provide the basic functionality does'nt seem to have made it upstream yet.. I sometimes wonder - Is it really so hard to push patches upstream?? Then I realize, I push patches in my spare time :) Which basically means that I am not driven by the chruning winds of business forces within the work environment dictating when and what patches I should be posting upstream :). Glad I still retain that flexibility. and probably the reason I do move seemingly faster - I always have the luxury to maintain focus on upstreaming my patchset.. it is all that hard when one writes in BOLD on one's office white board:
DID YOU CHECK YOUR PATCH STATUS: xyz
When one does'nt have a manager to remind one to follow up on patches upstream, I guess it makes it self driven - the most effective way of upstreaming.. it is long, it is arduous, it is constantLink monitoring, it is techno-political + there is a bit of learning how to write English involved.. but mostly it is one's personal drive and attitude I guess.. we all like to talk in a common language -> it tends to the "bottom posting", git format patch format etc.. bit of net-etiquette involved.. yeah we'r all mostly C-speaking people and would rather see code-ware than slide-ware and more importantly it should *work* ;)..

Felipe B's post is an excellent real-world read on what it is all about. It is not really that difficult.. it just needs practise.. We all help share what we learn.. but *you* (dear reader) need to step up and post a patch first for us to help tell you how to post a patch ;)