Is it possible to take obsolete Android device and port it to mainline kernel with Debian? (make RaspberryPi-like device)
Here is transcript of presentation:
0:00:00.000,0:00:04.529
I hope that you have enjoyed the first day of DORS
0:00:01.949,0:00:08.030
CLUC. My name is Dobrica PavlinuÃÂ
áiÃÂÃÂ
0:00:04.529,0:00:11.010
and today I will talk about to you about
0:00:08.030,0:00:15.480
how you can take the old Android device
0:00:11.010,0:00:18.840
and port the latest software on it. Over
0:00:15.480,0:00:23.580
there is my prop for this presentation
0:00:18.840,0:00:26.789
which tries to prove that it's really
0:00:23.580,0:00:29.609
possiblei. So the question is: is it
0:00:26.789,0:00:32.430
possible to take the old Android device,
0:00:29.609,0:00:37.020
in this case very old Android device, and
0:00:32.430,0:00:39.420
run latest Linux on it? In my case I
0:00:37.020,0:00:42.600
wanted to make something which would be
0:00:39.420,0:00:45.420
comparable to Respberry Pi which basically
0:00:42.600,0:00:49.980
for me means that I could run Debian on
0:00:45.420,0:00:56.100
it. So what is our device? Our device is
0:00:49.980,0:00:59.280
Tegra tablet from 2011 which is actually
0:00:56.100,0:01:02.280
quite a high-end tablet for that age, it
0:00:59.280,0:01:06.869
has two cores with 1 Gb RAM, it has
0:01:02.280,0:01:10.439
64 Gb of emmc storage, if you
0:01:06.869,0:01:15.140
remember in 2011 that's a huge amount of
0:01:10.439,0:01:20.189
storage, it has quite nice display and
0:01:15.140,0:01:22.740
Wi-Fi, GPS and stuff like that. The things
0:01:20.189,0:01:27.200
which were available from the
0:01:22.740,0:01:29.700
manufacturer is really old 2.6.36 kernel
0:01:27.200,0:01:33.180
fortunately available in source code
0:01:29.700,0:01:38.579
which is very helpful with quite a lot
0:01:33.180,0:01:41.490
of changes, there was also schematic
0:01:38.579,0:01:44.579
available from the OEM manufacturer
0:01:41.490,0:01:49.020
which actually produced that laptop for
0:01:44.579,0:01:51.299
Lenovo which was quite fortunate but not
0:01:49.020,0:01:54.149
as useful as you might think
0:01:51.299,0:01:56.520
so if you can't find the same schematic
0:01:54.149,0:02:01.950
for your Android tablet or device don't
0:01:56.520,0:02:05.729
don't despair it's not obligatory there
0:02:01.950,0:02:08.520
is quite good Tegra support in the
0:02:05.729,0:02:11.250
mainline kernel and as you'll see there
0:02:08.520,0:02:12.950
is also separately developed driver
0:02:11.250,0:02:16.310
which supports
0:02:12.950,0:02:19.819
both 2d and 3d acceleration as you can
0:02:16.310,0:02:22.580
see it's my prop over there, and they
0:02:19.819,0:02:24.830
were available really cheaply locally
0:02:22.580,0:02:28.849
basically I bought it at NjuÃÂ
ákalo
0:02:24.830,0:02:34.340
which is our local secondhand resale
0:02:28.849,0:02:37.250
kind of site. So what is the first step
0:02:34.340,0:02:39.620
if you want to do something like that? My
0:02:37.250,0:02:41.660
suggestion is to try to find the serial
0:02:39.620,0:02:44.750
port on your device. It would be really
0:02:41.660,0:02:48.500
really helpful when you try to do that
0:02:44.750,0:02:51.290
because first thing you want to do is
0:02:48.500,0:02:57.019
get some kind of feedback from your
0:02:51.290,0:03:00.049
tablet. In my case see the screen didn't
0:02:57.019,0:03:02.000
work so the serial port was really
0:03:00.049,0:03:06.440
invaluable to see whether I am actually
0:03:02.000,0:03:09.140
doing something or not. In this case I
0:03:06.440,0:03:12.950
had a schematic so I knew that there is
0:03:09.140,0:03:16.340
a four pin port somewhere on the tablet
0:03:12.950,0:03:18.680
on which is serial port, I also from the
0:03:16.340,0:03:20.420
schematic knew that this serial port is
0:03:18.680,0:03:23.329
connected directly to the Tegra
0:03:20.420,0:03:26.750
processor which in my case meant that
0:03:23.329,0:03:28.640
this serial port is 1.8 volts which
0:03:26.750,0:03:32.269
means that you don't want to connect it
0:03:28.640,0:03:36.320
to 3.3 volt device although Tegra CPUs
0:03:32.269,0:03:39.140
might be 3.3 volt tolerable but, I don't
0:03:36.320,0:03:44.150
know, you don't want to try that on your
0:03:39.140,0:03:47.239
device. But there is 1.8 volts serial
0:03:44.150,0:03:50.660
cable available from China which are
0:03:47.239,0:03:52.880
basically often often dubbed iPhone
0:03:50.660,0:03:57.430
cables because it uses the same voltage
0:03:52.880,0:03:57.430
but it's just the serial at 1.8 volts.
0:03:58.420,0:04:05.150
Why do I have the picture of the serial
0:04:01.310,0:04:08.090
port? Because in this case this was not
0:04:05.150,0:04:11.630
the only unpopulated connector of the on
0:04:08.090,0:04:14.780
the board with 4 pins, so learn from my
0:04:11.630,0:04:16.579
mistakes and don't try every possible
0:04:14.780,0:04:19.700
connector and until you find the right
0:04:16.579,0:04:21.950
one. It took me quite quite some time to
0:04:19.700,0:04:26.479
figure out that maybe it's under the
0:04:21.950,0:04:30.560
shield and it really was! The other thing
0:04:26.479,0:04:35.570
which you want to have some ability to
0:04:30.560,0:04:38.390
do and you almost always have: basically
0:04:35.570,0:04:42.229
you always have it -- is to be able to run
0:04:38.390,0:04:44.270
your own code on the device. Why do you
0:04:42.229,0:04:47.659
always have that on the Android devices?
0:04:44.270,0:04:50.479
Because when manufacturers create the
0:04:47.659,0:04:53.330
device you should be able
0:04:50.479,0:04:56.539
somehow to load the initial firmware on
0:04:53.330,0:05:00.050
it. So if we have any ARM device either
0:04:56.539,0:05:03.470
Allwinner, Rockchip, Tegra or anything,
0:05:00.050,0:05:07.190
there is a way to actually load your own
0:05:03.470,0:05:09.890
code on it, so that's not the showstopper.
0:05:07.190,0:05:12.860
Tegra is somewhat specific because there
0:05:09.890,0:05:17.320
is ability to lock Tegra bootloader
0:05:12.860,0:05:20.090
so you can't load the non-authorized
0:05:17.320,0:05:22.940
software on it, but this was not the case
0:05:20.090,0:05:25.640
in this case. In Tegra it's called APX
0:05:22.940,0:05:32.870
mode, you can enter it using two keyboard
0:05:25.640,0:05:35.599
presses and with tegrarcm from github
0:05:32.870,0:05:37.760
you can actually create the binary file
0:05:35.599,0:05:40.150
which you can send to your tablet and
0:05:37.760,0:05:43.909
make it do something.
0:05:40.150,0:05:46.219
This ability to to load
0:05:43.909,0:05:46.700
something on the device which is at that
0:05:46.219,0:05:49.430
point
0:05:46.700,0:05:51.530
unmodified enables you to actually
0:05:49.430,0:05:54.169
experiment safely because you can always
0:05:51.530,0:05:56.150
put something, try if it works, and you
0:05:54.169,0:05:59.450
didn't actually change the device itself.
0:05:56.150,0:06:01.520
Although this tablet was so unusable
0:05:59.450,0:06:02.960
because it had so old Anrdoid that
0:06:01.520,0:06:06.919
market didn't support
0:06:02.960,0:06:10.130
it so it wasn't so essential.
0:06:06.919,0:06:11.930
But you know, if this is your only device,
0:06:10.130,0:06:15.500
you probably don't want to break it in
0:06:11.930,0:06:19.070
your first experiment. But just have
0:06:15.500,0:06:20.990
in mind that you won't break your device,
0:06:19.070,0:06:24.530
it's always possible to recover it
0:06:20.990,0:06:27.409
whatever the device is. So far what we
0:06:24.530,0:06:29.479
have? We have working 2.6 kernel with all
0:06:27.409,0:06:32.240
the changes needed to actually make this
0:06:29.479,0:06:35.330
tablet work which isn't really very
0:06:32.240,0:06:36.230
useful but it's nice because we can see
0:06:35.330,0:06:39.380
what
0:06:36.230,0:06:42.440
did they change to make this tablet
0:06:39.380,0:06:45.590
work. I had a serial port and I had the
0:06:42.440,0:06:47.390
ability to run my own code. So what is
0:06:45.590,0:06:49.670
the first step? The first step is to have
0:06:47.390,0:06:52.940
some kind of bootloader which will load
0:06:49.670,0:06:57.230
our Linux kernel. On ARM devices this
0:06:52.940,0:07:00.410
is u-boot and since this tablet is
0:06:57.230,0:07:04.670
actually based on Ventana reference
0:07:00.410,0:07:06.830
design from Nvidia, which you can
0:07:04.670,0:07:11.450
actually figure out by looking at 2.6
0:07:06.830,0:07:14.090
kernel, it was really simple to try to
0:07:11.450,0:07:15.700
compile u-boot, try it out with APX
0:07:14.090,0:07:20.900
and it worked!
0:07:15.700,0:07:22.910
Few steps later I also ... got the
0:07:20.900,0:07:24.890
serial output out of the bootloader
0:07:22.910,0:07:26.840
which was the good first step, but
0:07:24.890,0:07:27.050
display was completely blank. So what did I
0:07:26.840,0:07:29.480
do?
0:07:27.050,0:07:31.910
I took the diff from the 2.6
0:07:29.480,0:07:34.880
kernel and looked what did they modify
0:07:31.910,0:07:38.330
to make the display work? I ported that
0:07:34.880,0:07:44.930
and I got even display in u-boot! mmm
0:07:38.330,0:07:49.940
Victory! I said "port changes" -- it might
0:07:44.930,0:07:52.460
seem extremely complicated or hard. but
0:07:49.940,0:07:54.260
basically that's it! On the left side you
0:07:52.460,0:07:57.200
see the changes which original
0:07:54.260,0:07:59.060
developers made for 2.6 kernel and on
0:07:57.200,0:08:00.950
the right side you can see the changes
0:07:59.060,0:08:03.770
which I made in u-boot to make it work
0:08:00.950,0:08:05.930
basically you compare the names of
0:08:03.770,0:08:12.410
the variables, you change the few ones
0:08:05.930,0:08:14.330
and it works. Once I had u-boot the
0:08:12.410,0:08:16.820
next step was actually to compile the
0:08:14.330,0:08:19.070
kernel and make it work. As I mentioned
0:08:16.820,0:08:21.710
earlier there is the grate driver
0:08:19.070,0:08:26.120
project which basically supports 2d and
0:08:21.710,0:08:28.460
3d acceleration on Tegra devices so I
0:08:26.120,0:08:33.530
actually started with it because I
0:08:28.460,0:08:36.700
wanted 2d and 3d and video decoding I
0:08:33.530,0:08:43.010
started in the same way I looked at 2.6
0:08:36.700,0:08:46.340
kernel tried to port the display, it
0:08:43.010,0:08:49.520
should be possible to define display
0:08:46.340,0:08:53.120
in device tree itself, for some reason
0:08:49.520,0:08:56.990
it did not work for me so this was few lines
0:08:53.120,0:09:00.410
of diff in kernel itself, but other
0:08:56.990,0:09:02.900
than that, all the other things were
0:09:00.410,0:09:06.260
basically device tree configuration.
0:09:02.900,0:09:09.770
I had to configure the buttons
0:09:06.260,0:09:14.510
on the laptop to generate keyboard
0:09:09.770,0:09:16.700
events and from 2.6 kernel it wasn't
0:09:14.510,0:09:19.160
clear whether the button is both pull-up
0:09:16.700,0:09:22.010
or pulldown but you try one, you try the
0:09:19.160,0:09:24.320
other, and if you make a mistake, if you
0:09:22.010,0:09:26.660
said that button is pulled down and it's
0:09:24.320,0:09:28.190
pull up the thing which will happen is
0:09:26.660,0:09:31.580
that when you press the button it
0:09:28.190,0:09:34.100
it won't release, so you will figure it
0:09:31.580,0:09:35.750
out. Basically some buttons are pull up
0:09:34.100,0:09:39.130
some buttons are pull down, you just
0:09:35.750,0:09:42.650
experiment a little and it will work out.
0:09:39.130,0:09:44.720
Then I added a few additional
0:09:42.650,0:09:47.630
modules which were supported in upstream
0:09:44.720,0:09:50.930
kernel already, like a temperature sensor
0:09:47.630,0:09:54.800
compass and there is also in tablet
0:09:50.930,0:09:56.690
accelerometer which should be
0:09:54.800,0:09:59.300
supported by the kernel module, but
0:09:56.690,0:10:03.470
currently doesn't work -- work in
0:09:59.300,0:10:06.050
progress -- but all in all this diff --stat
0:10:03.470,0:10:09.830
at the bottom of the slide are all the
0:10:06.050,0:10:13.040
changes which were required to make this
0:10:09.830,0:10:19.270
tablet, over there, which actually started
0:10:13.040,0:10:24.800
screensaver, working on the latest kernel
0:10:19.270,0:10:27.170
not really so hard at all, right? As the
0:10:24.800,0:10:29.540
next step and probably the most
0:10:27.170,0:10:32.030
important thing which I learned during
0:10:29.540,0:10:35.300
this process, is actually that you want
0:10:32.030,0:10:37.190
to develop using NFS root. You don't
0:10:35.300,0:10:40.040
actually want to experiment on the
0:10:37.190,0:10:45.020
device itself because it's so convenient
0:10:40.040,0:10:47.030
to actually edit files in VI on your NFS
0:10:45.020,0:10:50.720
server which in my case is just a
0:10:47.030,0:10:52.550
ordinary laptop instead of editing it on
0:10:50.720,0:10:54.230
the device itself especially if the
0:10:52.550,0:10:57.520
device itself doesn't have the keyboard.
0:10:54.230,0:11:00.500
Right now I do have the keyboard but
0:10:57.520,0:11:03.620
when I started I didn't have any device
0:11:00.500,0:11:06.650
and it's you know it's really much more
0:11:03.620,0:11:10.940
variable to do that on on your normal
0:11:06.650,0:11:15.950
development machine. NFS will also enable
0:11:10.940,0:11:18.140
you to to try different devices but the
0:11:15.950,0:11:21.620
prerequisite for that is actually to
0:11:18.140,0:11:23.290
have the USB Ethernet device which is
0:11:21.620,0:11:26.320
supported by u-boot
0:11:23.290,0:11:29.360
unfortunately u-boot support very few
0:11:26.320,0:11:33.250
USB Ethernet dongle so you will have to
0:11:29.360,0:11:36.529
find the one which is supported or port
0:11:33.250,0:11:39.350
changes from some other USB dongle which
0:11:36.529,0:11:42.650
is also not that hard but it wasn't
0:11:39.350,0:11:47.210
needed because I actually had a dongle
0:11:42.650,0:11:49.100
which is supported. The second
0:11:47.210,0:11:53.330
interesting thing I learned here is the
0:11:49.100,0:11:57.160
one marked here in yellow which is that
0:11:53.330,0:12:00.950
the kernel configuration
0:11:57.160,0:12:04.460
because you say to u-boot ok please
0:12:00.950,0:12:06.860
use the DHCP acquire MAC address and
0:12:04.460,0:12:09.830
then load the kernel and initramfs
0:12:06.860,0:12:13.160
from the from the server and once
0:12:09.830,0:12:16.880
you start the kernel the kernel also has
0:12:13.160,0:12:20.900
the option to acquire address over DHCP but
0:12:16.880,0:12:24.920
unfortunately that didn't work I suspect
0:12:20.900,0:12:28.520
that it's problem with initialization of
0:12:24.920,0:12:31.150
the USB interface in kernel so the
0:12:28.520,0:12:34.430
interface is not initialized correctly
0:12:31.150,0:12:37.490
or something, but you can always hard
0:12:34.430,0:12:40.880
code the IP address and that worked. If
0:12:37.490,0:12:42.709
you want more info about making u-boot
0:12:40.880,0:12:45.770
work with the NFS root and
0:12:42.709,0:12:49.010
configuration of dnsmasq the last link
0:12:45.770,0:12:52.910
here is actually the wiki page in which
0:12:49.010,0:12:55.220
you can find more information. And then I
0:12:52.910,0:12:57.200
had the tablet which was somewhat
0:12:55.220,0:13:00.860
working but the problem was that I
0:12:57.200,0:13:03.560
couldn't charge it. Since this tablet is
0:13:00.860,0:13:06.830
from 2011 you would expect that the
0:13:03.560,0:13:09.950
battery is quite dead and it really is
0:13:06.830,0:13:12.260
quite dead but it's really annoying that
0:13:09.950,0:13:13.850
you can actually work several hours on
0:13:12.260,0:13:16.130
your tablet and then you have to take
0:13:13.850,0:13:16.400
another device which was charging during
0:13:16.130,0:13:20.600
that
0:13:16.400,0:13:25.430
time so I wanted to somehow make it work
0:13:20.600,0:13:27.590
to make it work always, to have it
0:13:25.430,0:13:32.560
always powered on and to be able to charge
0:13:27.590,0:13:35.510
it from the USB. The problem is that this
0:13:32.560,0:13:38.540
particular tablet is very sensitive to
0:13:35.510,0:13:42.580
the 5 volt rail and if you don't have
0:13:38.540,0:13:45.920
stable 5 volt rail it will try to
0:13:42.580,0:13:48.530
to pull as much as 2 amps if the battery
0:13:45.920,0:13:50.870
is totally flat and if the voltage drops
0:13:48.530,0:13:52.910
a little bit below 5 volts it will
0:13:50.870,0:13:55.580
just give up and say okay I won't charge
0:13:52.910,0:13:58.010
so the tablet was charging quite nice
0:13:55.580,0:14:00.800
when powered off but didn't charge with
0:13:58.010,0:14:03.590
power on, so what could I do?
0:14:00.800,0:14:08.660
Other than draw nice graphs which show
0:14:03.590,0:14:11.930
my problems? Well I can look at 2.6
0:14:08.660,0:14:14.630
kernel and see what did they do to actually
0:14:11.930,0:14:19.130
make it work? This tablet is also
0:14:14.630,0:14:21.650
somewhat specific in regards to other
0:14:19.130,0:14:25.970
Android tablets because it has another
0:14:21.650,0:14:28.250
processor which is 8051 core which
0:14:25.970,0:14:31.100
basically talks with battery so I don't
0:14:28.250,0:14:33.950
have direct connection with the
0:14:31.100,0:14:36.860
battery controller but I have it through
0:14:33.950,0:14:39.620
the firmware in that microcontroller
0:14:36.860,0:14:43.610
which is connected to the Tegra device
0:14:39.620,0:14:46.400
using i2c. This was in one sense annoying
0:14:43.610,0:14:47.860
because if I could directly drive the
0:14:46.400,0:14:50.480
battery charger it would be much easier
0:14:47.860,0:14:53.000
but on the other hand that meant that
0:14:50.480,0:14:55.850
the solution was rather simple I just
0:14:53.000,0:14:59.060
had to send one i2c
0:14:55.850,0:15:02.080
command copied from the 2.6 kernel and
0:14:59.060,0:15:07.850
the tablet would start charging
0:15:02.080,0:15:12.560
win/win/win and as you can see on the
0:15:07.850,0:15:17.240
demo after recompiling the whole GL
0:15:12.560,0:15:21.230
stack including libdrm, mesa and opentegra
0:15:17.240,0:15:26.900
video driver I actually have x11 running
0:15:21.230,0:15:29.680
on it without any problems whatsoever
0:15:26.900,0:15:32.200
So what works and what doesn't?
0:15:29.680,0:15:34.000
from the i2c devices on the left which
0:15:32.200,0:15:36.820
are basically the list of the devices
0:15:34.000,0:15:40.240
from the 2.6 kernel we can see that
0:15:36.820,0:15:43.510
audio, charging, compas, power and
0:15:40.240,0:15:45.910
temperature are working as is, the things
0:15:43.510,0:15:47.620
which are denoted by the small hand are
0:15:45.910,0:15:49.500
actually the things which I had to do
0:15:47.620,0:15:53.140
something
0:15:49.500,0:15:57.370
unfortunately the cameras are not
0:15:53.140,0:16:00.820
supported but you know they're lousy
0:15:57.370,0:16:03.490
cameras from 2011 and this tablet is
0:16:00.820,0:16:07.149
still better than the Raspberry Pi
0:16:03.490,0:16:11.709
diplay works, HDMI probably works, I didn't
0:16:07.149,0:16:14.680
really test it the main drawback is that
0:16:11.709,0:16:17.740
the touchscreen on this device is
0:16:14.680,0:16:20.970
the SPI device which currently doesn't
0:16:17.740,0:16:24.490
work for me the SPI doesn't work at all
0:16:20.970,0:16:26.680
keys were really easy those were the key
0:16:24.490,0:16:31.450
is connected to GPIO just a little bit
0:16:26.680,0:16:35.290
of device tree, the vibrator there is a
0:16:31.450,0:16:38.230
small vibrating motor in the tablet,
0:16:35.290,0:16:40.209
actually doesn't work for me I really
0:16:38.230,0:16:44.860
don't know why there is nothing special
0:16:40.209,0:16:47.680
in 2.6 kernel for it but if I toggle the
0:16:44.860,0:16:51.520
pin nothing happens and it does work in
0:16:47.680,0:16:54.339
2.6 so more work needs to be done
0:16:51.520,0:16:58.680
there is also the proximity sensor which
0:16:54.339,0:17:02.500
works also one simple GPIO there is the
0:16:58.680,0:17:05.920
Wi-Fi and 3G modem which works because
0:17:02.500,0:17:08.589
it's the simple USB device there is the
0:17:05.920,0:17:11.679
internal flash connected to MMC which
0:17:08.589,0:17:14.230
also works and the SD card I think that
0:17:11.679,0:17:16.660
SD card actually works but it's a big SD
0:17:14.230,0:17:24.250
card so I just didn't have any handy to
0:17:16.660,0:17:28.390
test it. [Adapter?] yeah sure but with 64 Gb
0:17:24.250,0:17:31.000
of emmc which has 40 Mb of
0:17:28.390,0:17:35.890
transfer rate why would I even try the
0:17:31.000,0:17:39.100
SD card right? So was it worth it? For me
0:17:35.890,0:17:42.320
it surely is! If the goal was to
0:17:39.100,0:17:48.440
be able to type apt-get update
0:17:42.320,0:17:50.750
I have achieved that goal. So if you have
0:17:48.440,0:17:53.960
more devices you can spend one of
0:17:50.750,0:17:55.850
them to actually figure out what is what
0:17:53.960,0:17:59.389
is on the board, and this is one of the
0:17:55.850,0:18:01.850
tablets disassembled into into separate
0:17:59.389,0:18:07.899
pieces still working as you can see it
0:18:01.850,0:18:11.480
has the LED it works but there are also
0:18:07.899,0:18:14.480
few things left to do. For a start the
0:18:11.480,0:18:17.120
SPI controller doesn't work which is
0:18:14.480,0:18:18.860
quite strange I think I configured
0:18:17.120,0:18:21.559
everything but surely there is the
0:18:18.860,0:18:29.059
problem between me and and the code I
0:18:21.559,0:18:31.940
wrote. In mainstream kernel there is similar
0:18:29.059,0:18:36.799
driver for the touchpad which is used in
0:18:31.940,0:18:40.730
surface Microsoft Surface 3 but that
0:18:36.799,0:18:43.519
driver actually use ACPI tables to
0:18:40.730,0:18:45.259
initialize and on the arm devices we
0:18:43.519,0:18:47.299
would need the device tree to do that
0:18:45.259,0:18:49.659
and I actually wrote the code which
0:18:47.299,0:18:51.649
actually query the device tree
0:18:49.659,0:18:54.440
it's really simple you just
0:18:51.649,0:18:56.330
you just add a few defines in kernel
0:18:54.440,0:18:59.269
module and it will also query the device
0:18:56.330,0:19:03.769
tree but since the SPI doesn't work for
0:18:59.269,0:19:07.100
me currently unfortunately touch as
0:19:03.769,0:19:10.039
of today doesn't still work embedded
0:19:07.100,0:19:12.769
controller will need a little bit more
0:19:10.039,0:19:15.139
work and it's actually more essential
0:19:12.769,0:19:18.320
because I would really like to be able
0:19:15.139,0:19:21.019
to plug in the power and for
0:19:18.320,0:19:22.899
battery to start charging immediately as
0:19:21.019,0:19:26.330
opposed to me starting the shell script
0:19:22.899,0:19:30.919
but you know for now it actually works
0:19:26.330,0:19:33.169
and cameras are are supported the
0:19:30.919,0:19:36.470
problem with cameras it should be really
0:19:33.169,0:19:39.610
easy from the perspective of the kernel
0:19:36.470,0:19:42.889
driver developer the cameras are
0:19:39.610,0:19:45.080
relatively simple i2c devices because
0:19:42.889,0:19:48.320
you just have to set up the camera
0:19:45.080,0:19:51.470
the cameras are CSI and they will start
0:19:48.320,0:19:54.400
streaming frames to memory of Tegra
0:19:51.470,0:19:56.559
Tegra hardware support decode of
0:19:54.400,0:20:03.730
that in memory and all should be golden
0:19:56.559,0:20:06.550
but the video4linux 2 API in kernel
0:20:03.730,0:20:09.040
is currently changing so all the
0:20:06.550,0:20:11.590
examples for the camera similar to
0:20:09.040,0:20:14.260
mine are actually examples for the old
0:20:11.590,0:20:19.990
way of doing things as opposed to new
0:20:14.260,0:20:23.640
one so this is somewhat something which
0:20:19.990,0:20:27.340
I have to do at some later date
0:20:23.640,0:20:29.410
still real Linux distribution on
0:20:27.340,0:20:32.410
this device is much more useful than
0:20:29.410,0:20:35.140
obsolete Android and if you enjoy this
0:20:32.410,0:20:38.260
or you have some Tegra 2 device you can
0:20:35.140,0:20:40.870
find additional notes here on the other
0:20:38.260,0:20:43.630
hand if you don't have Tegra device but
0:20:40.870,0:20:46.840
some other Android tablet on which you
0:20:43.630,0:20:49.660
want to do something like this you can
0:20:46.840,0:20:51.400
try some of the following links if you
0:20:49.660,0:20:55.300
have allwinner
0:20:51.400,0:20:57.280
or rockchip device I suggest to take a
0:20:55.300,0:21:00.850
look at armbian which is probably
0:20:57.280,0:21:04.540
the most well-known and best ARM based
0:21:00.850,0:21:06.760
Linux distro for the devices if you have
0:21:04.540,0:21:12.400
the OMAP based device which is
0:21:06.760,0:21:16.540
basically the Nexus 7 or older Nexus
0:21:12.400,0:21:19.000
phones there is talk from fosdem which
0:21:16.540,0:21:21.490
goes into more details what you can do
0:21:19.000,0:21:26.380
they are also quite well supported in -
0:21:21.490,0:21:29.350
in mainstream kernel and the last
0:21:26.380,0:21:33.429
alternative is postmarketOS which goal
0:21:29.350,0:21:36.280
is to bring longer life to all the
0:21:33.429,0:21:39.160
devices so in a sense similar goal to
0:21:36.280,0:21:43.600
mine it's based on Alpine which is
0:21:39.160,0:21:46.090
basically why I didn't use that but it
0:21:43.600,0:21:48.059
does have the support for Samsung Galaxy
0:21:46.090,0:21:53.290
Tab 10 which is also
0:21:48.059,0:21:55.840
tera device and this source
0:21:53.290,0:21:59.110
code for this device actually got me
0:21:55.840,0:22:01.179
the courage to actually try this because
0:21:59.110,0:22:03.820
I could see all the changes between main
0:22:01.179,0:22:05.980
line and support needed for one Tegra
0:22:03.820,0:22:07.540
device which wasn't supported before and
0:22:05.980,0:22:10.960
I said
0:22:07.540,0:22:13.500
this doesn't seem so hard it wasn't it
0:22:10.960,0:22:18.490
wasn't useful for any practical
0:22:13.500,0:22:20.500
practical I didn't copy any code I the
0:22:18.490,0:22:23.740
tablets are different enough that it
0:22:20.500,0:22:26.260
wasn't directly reusable but it gave me
0:22:23.740,0:22:29.380
the courage to actually
0:22:26.260,0:22:32.830
try it out so hopefully this will
0:22:29.380,0:22:35.770
motivate you to revive some of your old
0:22:32.830,0:22:44.320
Android devices. Do you have any
0:22:35.770,0:22:47.890
questions? this the same grate driver
0:22:44.320,0:22:50.890
supports Tegra 3 the Tegra 2 and newer
0:22:47.890,0:22:53.320
so Tegra 3 is also supported
0:22:50.890,0:22:56.080
although depending on which Tegra you
0:22:53.320,0:23:00.030
have these days they usually have locked
0:22:56.080,0:23:00.030
bootloader but...
0:23:00.630,0:23:10.320
if you can update Android on your
0:23:06.690,0:23:15.510
Tegra device there is a possibility to
0:23:10.320,0:23:18.900
actually replace the Android kernel with
0:23:15.510,0:23:22.470
the kernel which has kexec as opposed
0:23:18.900,0:23:25.650
of using u-boot to boot the kernel you
0:23:22.470,0:23:27.390
actually install your own kernel which
0:23:25.650,0:23:29.910
is some version which is supported on
0:23:27.390,0:23:32.400
your device and you then you can do with
0:23:29.910,0:23:35.040
the kexec to the current kernel so
0:23:32.400,0:23:38.570
it's also possible I actually do have I
0:23:35.040,0:23:41.130
actually got a new friend from Germany
0:23:38.570,0:23:42.960
during this project because I started
0:23:41.130,0:23:45.180
documenting everything on the wiki as I
0:23:42.960,0:23:48.330
was working and he contacted me and said
0:23:45.180,0:23:51.330
oh I have the Tegra tablet also for two
0:23:48.330,0:23:53.130
years I'm so happy I found you and he
0:23:51.330,0:23:55.140
actually sent me the keyboard this is
0:23:53.130,0:23:58.110
why I now have the keyboard and didn't
0:23:55.140,0:24:03.600
have it and this one is locked so I will
0:23:58.110,0:24:05.430
try that that kexec trick in the
0:24:03.600,0:24:08.190
future and document it on the wiki so
0:24:05.430,0:24:20.580
this might be helpful any other
0:24:08.190,0:24:24.510
questions? [How much did it cost?] It was it was between 100
0:24:20.580,0:24:27.060
between 80 and 100 kunas depending on
0:24:24.510,0:24:30.470
the on the state of disrepair which is
0:24:27.060,0:24:35.760
for the international audience between
0:24:30.470,0:24:39.770
11-12 euros and like 14 right so they
0:24:35.760,0:24:39.770
were really cheap I have a bunch of them
0:24:43.290,0:24:50.660
[Applause]