[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-omap
Subject:    Re: [android-internals] Re: Android on Nokia n810 (OMAP2420)
From:       "andrzej zaborowski" <balrogg () gmail ! com>
Date:       2008-04-06 23:41:30
Message-ID: fb249edb0804061641s57f52b15x553c6cb9366909b6 () mail ! gmail ! com
[Download RAW message or body]

On 06/04/2008, Georges Toth <georges.toth@gmail.com> wrote:
> >  Fortunately the userspace can partially ignore the
> > charging issue because the RETU (now Betty) chip takes care of that in
> > the hardware.  Charging / charger-cable / power-button / battery-life
> > states are readable from /sys and /dev.
> >
> >
>  Hmm where exactly can you read that info from ?
>  I quickly searched through sysfs, proc and dev but without much luck  :-)

The battery and charger are connected to the ADC in retu which has 14
channels.  I thought I saw an interface in the stock n810 kernel to
get their readings through /sys but apparently there isn't any, except
for the "Headset detection" channel, my bad.  In this case, to read
the values you need to open /dev/retu and issue RETU_IOCH_ADC_READ
ioctl (number _IO(0x60, 0x03)) with the channel number as parameter.
It returns the 12-bit ADC value. The channel names are the following:

0 - Ground
1 - BSI
2 - Battery temperature
3 - Charger voltage
4 - Headset detection
5 - Hook detection
6 - RF GP
7 - Wideband Tx detection
8 - Battery voltage
9 - Ground
10 - Light sensor
11 - Light sensor temperature
12 - Backup battery voltage
13 - RETU temperature
(the names come from the NOLO bootloader help messages)

The light sensor is actually connected to a separate ADC whose value
is available in /sys/class/hwmon/... somewhere.

When BME is running the already processed battery state can be read
from hal with:
$ hal-get-property --udi /org/freedesktop/Hal/devices/bme --key
battery.charge_level.percentage

("hal-device /org/freedesktop/Hal/devices/bme" gives more info)

>
>
> > The best bet for a distro is probably to leave the maemo "initfs",
> > which contains closed-source DSME / BME / flasher, in place and let
> > the custom rootfs run on top of it.  If you need some details about
> > retu / tahvo driving / bootloading, I may be able to tell because I
> > recently had to poke on it for a different project.
> >
> >
>  Should I get android to work correctly it would be nice to automatically
> start android after booting the n810.

Poky works that way, the initfs boots first (the stock initfs,
unmodified) and eventually chroot's into the rootfs which is a Poky
image and the system starts automatically but you still get the stock
nokia flasher and charger screen in initfs.

>  Thus if you have any info on setting up wifi automatically from a script
> and what exactly to disable to prevent the system from starting Xomap, dbus,
> hal etc... that would be nice :-)

I haven't looked into the software side much, but I'm sure that if you
replace the rootfs, Xomap won't start.  The initfs has a /linuxrc file
that can be custimsed.

>
>
> >
> > >  Next would be to try to get the framebuffer driver hacked to work with
> the
> > > m5 image ... the framebuffer driver doesn't support double buffering
> thus we
> > > only get a black screen :-(
> > >
> > >
> > I understand the userspace is going to be open-source at some point,
> > which would render this work a bit useless.  If it doesn't get
> > open-sourced then it's a waste of time either way I think?
> >
> >
>  According to what I've read so far it will be open-sourced as soon as the
> first devices start to appear...which probably won't be anytime soon
>
>  But even then that work wouldn't be useless because Google won't release a
> framebuffer driver for Nokia n800/810 ... so if one wants to be able to run
> m5 and future releases, somebody has to modify the current driver to be
> compatible with android...if that is even possible.

What I mean is that this is the kind of issue that takes probably
minutes to fix in the userspace for a person that has the sources, but
can take days to a person trying to work around the userspace bug in
the kernel, time that could be spent on actual free software,
collaborative projects.  The issue as I understand is in the userspace
which is written in a way that's not portable between framebuffers,
probably ignoring existing standards and existing libraries for
accessing framebuffers.
-- 
Please do not print this email unless absolutely necessary. Spread
environmental awareness.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]