A short info which is a little less hardware-related: I've just created an account with github in order to actively contribute to XDA's Hashcode kernel development. My github page is available at https://github.com/stylon and the Kindle Fire kernel branch at https://github.com/stylon/kernel_omap_otter-common.
I've already collected a few patches and I'm working on a rewrite of the Ambient Light Sensor driver and think that the github repository is the right place to publish them.
Tuesday, February 19, 2013
Thursday, January 31, 2013
My Kindle Fire(s)
My passion for the Kindle Fire started shortly after developing a plan for my project in mid 2011. Every now and then I'll drop a few more details about that plan here, too, but now I want to tell you more about how I got my 2 Kindle Fire(s).
Ever since the Kindle Fire came out in November 2011 I wanted to have it. My plan needed a powerful dual-core embedded platform with a good and bright display and a capacitive touchscreen. The Kindle Fire had a lot, not more than I needed. Actually less, but it's good at what it offers and that counts most for me. The rest I could hack and mod myself, learn something by doing so and have some fun at the same time. I had known the Pandaboard and Blaze from Texas Instruments before, so I was familar and happy with that basic TI platform.
At that time my passion had almost gone with the Blackberry Playbook already. But that was not as open as the Kindle Fire. And it was soooo expensive. Blackberry clearly missed the bus... train... what do I say? ...rocket to enter the tablet market! And very much because they got the price wrong. The hardware was very right and I would still prefer it over the Kindle Fire. But the Fire is 1) way cheaper and 2) (more) open!
Ok, talking about pure hardware-mods here, you could argue now: simply ignore that locked Blackberry bootloader and set the OMAP4 SYS_BOOT bits right and you'll get around it. That's true! But then what about the operating system? 3) Amazon releases at least the source code. Well, ...releases! They obviously don't care about us hackers and developers (who should we blame to not include a proper kernel-.config?).
The summary of this: the Kindle Fire is just open enough to be an attractive hacking platform, while the Blackberry Playbook is just closed enough not to be! So, finally my passion went with the Kindle Fire. The absolute right timing for my plan! Amazon, how did you know that I would need...?
Honestly, the story is a bit different and I need to take another short detour. I was a bit more impatient, so in September 2011 I started on my plan with a Huawei Slim S7. What a difference compared to the Kindle Fire lateron: 800MHz single core, 800x480 display, *not* an IPS panel (colors? yes, a lot, but you've no control over them... :-) ), only 4G ROM (what can you do with even less than 8G?), but GPS, WLAN, BT, 3G and the whole bunch of nice toy sensors. Actually not even worth starting to talk about hardware-mods, because it had everything (except a Geiger-Müller counter maybe). I played around with it for a while to learn how to hack Android systems. And hacking here means: get rid of Android, install your own Linux from scratch! A good experience. I learned that I had missed that for some years.
Finally it got 2012 and then March and I had the chance to travel to the US for some business reason. I ordered a Kindle Fire ($199=€150) and learned that Amazon even delivers to hotels (so you don't need to be a permanent resident). Back home I hacked my fresh Fire in the same way as that Huawei Slim S7 and I was immediately happy with everything. That was my Kindle Fire #1.
You guess it already: my plan needs a second Kindle Fire! And that I bought on ebay. A used one, but rarely used. Actually not much more than my fresh new one from March. So, my Kindle Fire #2 was there, crafted back in January.
Ever since the Kindle Fire came out in November 2011 I wanted to have it. My plan needed a powerful dual-core embedded platform with a good and bright display and a capacitive touchscreen. The Kindle Fire had a lot, not more than I needed. Actually less, but it's good at what it offers and that counts most for me. The rest I could hack and mod myself, learn something by doing so and have some fun at the same time. I had known the Pandaboard and Blaze from Texas Instruments before, so I was familar and happy with that basic TI platform.
At that time my passion had almost gone with the Blackberry Playbook already. But that was not as open as the Kindle Fire. And it was soooo expensive. Blackberry clearly missed the bus... train... what do I say? ...rocket to enter the tablet market! And very much because they got the price wrong. The hardware was very right and I would still prefer it over the Kindle Fire. But the Fire is 1) way cheaper and 2) (more) open!
Ok, talking about pure hardware-mods here, you could argue now: simply ignore that locked Blackberry bootloader and set the OMAP4 SYS_BOOT bits right and you'll get around it. That's true! But then what about the operating system? 3) Amazon releases at least the source code. Well, ...releases! They obviously don't care about us hackers and developers (who should we blame to not include a proper kernel-.config?).
The summary of this: the Kindle Fire is just open enough to be an attractive hacking platform, while the Blackberry Playbook is just closed enough not to be! So, finally my passion went with the Kindle Fire. The absolute right timing for my plan! Amazon, how did you know that I would need...?
Honestly, the story is a bit different and I need to take another short detour. I was a bit more impatient, so in September 2011 I started on my plan with a Huawei Slim S7. What a difference compared to the Kindle Fire lateron: 800MHz single core, 800x480 display, *not* an IPS panel (colors? yes, a lot, but you've no control over them... :-) ), only 4G ROM (what can you do with even less than 8G?), but GPS, WLAN, BT, 3G and the whole bunch of nice toy sensors. Actually not even worth starting to talk about hardware-mods, because it had everything (except a Geiger-Müller counter maybe). I played around with it for a while to learn how to hack Android systems. And hacking here means: get rid of Android, install your own Linux from scratch! A good experience. I learned that I had missed that for some years.
Finally it got 2012 and then March and I had the chance to travel to the US for some business reason. I ordered a Kindle Fire ($199=€150) and learned that Amazon even delivers to hotels (so you don't need to be a permanent resident). Back home I hacked my fresh Fire in the same way as that Huawei Slim S7 and I was immediately happy with everything. That was my Kindle Fire #1.
You guess it already: my plan needs a second Kindle Fire! And that I bought on ebay. A used one, but rarely used. Actually not much more than my fresh new one from March. So, my Kindle Fire #2 was there, crafted back in January.
Wednesday, January 30, 2013
The Ambient Light Sensor
Ok, it's a while ago that I posted something here. What did happen? Actually, I was fairly busy doing some good research on the Kindle Fire's hard- and software side and I'll post the summary of that analysis here over the next couple of weeks.
The topic I would like to start with is Kindle Fire's ambient light sensor. Oh, you don't have any on your Kindle Fire? Maybe you never noticed it as Amazon turned it off with the first software update for some unknown reason (most likely, because it acted too nervously). Some users actually did notice, unfortunately only after the software update had removed the option on the Android GUI, but then could not undo the update. However, in my today's blog entry we're going to activate that sensor again.
So, where is that thing? Here's a not-so-good close shot of it:
The ambient light sensor is behind the touchscreen glass and measures the intensity of surrounding light through a tiny hole. This hole is located in the upper left corner and some may have misjudged this to be a camera.
What else except for a Kindle Fire do we need to try it out? Basically, Amazon's released source code of the kernel or any other kernel source adapted to the Kindle Fire is enough (like the 3.0 series that is being maintained by Hashcode on xda-developers).
The sensor itself is a SenseTek STK22x7 and the kernel driver is in reasonable, but not very good shape and comes with those kernel sources. As the sensor is attached to the mainboard via one of OMAP4's I²C busses, it's located in $KERNEL_SRC/drivers/i2c/SenseTek. Compilation can easily be enabled via make config/menuconfig (in the submenu of I²C drivers), but still it won't detect the sensor simply because prior to releasing the kernel sources Amazon's developers seem to have disabled some of the registering code in the driver.
As all the basic code is there (stk_i2c_als22x7_kcx.c), you only need to change the last 2 occurrences of #if 0 in that file to #if 1 which re-enables that registering code. I myself also changed a few other things:
This needs to be done via sysfs. The sysfs entries of the driver register at /sys/devices/platform/stk-oss and via
you can enable lux measurements. Simply enable it, start continuous probing via
and cast different levels of light at the sensor from e.g. a torch light or a lighter and you will see how the values that come back from that device file will change.
That's it... :-)
The driver code itself can definitely use some cleanups as suspend doesn't work very well yet and it's still full of debug code. For Android you may need some extra work as this just enables the kernel-level driver.
The topic I would like to start with is Kindle Fire's ambient light sensor. Oh, you don't have any on your Kindle Fire? Maybe you never noticed it as Amazon turned it off with the first software update for some unknown reason (most likely, because it acted too nervously). Some users actually did notice, unfortunately only after the software update had removed the option on the Android GUI, but then could not undo the update. However, in my today's blog entry we're going to activate that sensor again.
So, where is that thing? Here's a not-so-good close shot of it:
The ambient light sensor is behind the touchscreen glass and measures the intensity of surrounding light through a tiny hole. This hole is located in the upper left corner and some may have misjudged this to be a camera.
What else except for a Kindle Fire do we need to try it out? Basically, Amazon's released source code of the kernel or any other kernel source adapted to the Kindle Fire is enough (like the 3.0 series that is being maintained by Hashcode on xda-developers).
The sensor itself is a SenseTek STK22x7 and the kernel driver is in reasonable, but not very good shape and comes with those kernel sources. As the sensor is attached to the mainboard via one of OMAP4's I²C busses, it's located in $KERNEL_SRC/drivers/i2c/SenseTek. Compilation can easily be enabled via make config/menuconfig (in the submenu of I²C drivers), but still it won't detect the sensor simply because prior to releasing the kernel sources Amazon's developers seem to have disabled some of the registering code in the driver.
As all the basic code is there (stk_i2c_als22x7_kcx.c), you only need to change the last 2 occurrences of #if 0 in that file to #if 1 which re-enables that registering code. I myself also changed a few other things:
- removed probing for the 3rd I²C address 0x38. There's simply nothing there to probe for. I assume there's more than 1 flavour of the STK22x7 with additional features like a proximity sensor or IRQ-based triggers
- changed the STK22X7 config variables to tristate in Kconfig to be able to compile the driver as a module for further development (worked out of the box except for cleanly unloading the module)
This needs to be done via sysfs. The sysfs entries of the driver register at /sys/devices/platform/stk-oss and via
echo 1 > /sys/devices/platform/stk-oss/als_enable
you can enable lux measurements. Simply enable it, start continuous probing via
watch -n 1 cat /sys/devices/platform/stk-oss/lux
and cast different levels of light at the sensor from e.g. a torch light or a lighter and you will see how the values that come back from that device file will change.
That's it... :-)
The driver code itself can definitely use some cleanups as suspend doesn't work very well yet and it's still full of debug code. For Android you may need some extra work as this just enables the kernel-level driver.
Tuesday, June 26, 2012
No Android, but Linux
Of course, I've a little (maybe some would call it huge) project in mind with my 2 Kindle Fires. One part of that project is to potentially not use Android on the Kindle at all. There are various reasons for this, but the major one is boot time. In that project I can't keep the Kindle Fire in its well-working suspend mode, from which Android awakes really quickly. Instead it'll boot freshly each time and my plan is to get the boot time down to under 5 seconds.
So, currently KF#2 does no longer contain any Android files. It already boots in ~8 seconds to a command line prompt of a small Linux system, but my hope is to get that further down. The kernel takes ~3 seconds, but x-loader and u-boot are my main obstacles right now. u-boot is a mess to understand and Amazon didn't make the job easier by adding support for the Fire to it. I even considered to get rid of u-boot and boot directly into the kernel from x-loader, but that would also mean to miss some nice features (boot logo, fastboot, etc.). Yes, I still use fastboot and adb from android, mainly because I find them very comfortable to use.
I've built that small linux system using Buildroot and used the (non-Android) framebuffer OpenGL ES drivers from TI, though getting the SGX drivers working was tricky. On the other side the OpenGL ES demos from the same package and some own test programs run nicely already.
So, currently KF#2 does no longer contain any Android files. It already boots in ~8 seconds to a command line prompt of a small Linux system, but my hope is to get that further down. The kernel takes ~3 seconds, but x-loader and u-boot are my main obstacles right now. u-boot is a mess to understand and Amazon didn't make the job easier by adding support for the Fire to it. I even considered to get rid of u-boot and boot directly into the kernel from x-loader, but that would also mean to miss some nice features (boot logo, fastboot, etc.). Yes, I still use fastboot and adb from android, mainly because I find them very comfortable to use.
I've built that small linux system using Buildroot and used the (non-Android) framebuffer OpenGL ES drivers from TI, though getting the SGX drivers working was tricky. On the other side the OpenGL ES demos from the same package and some own test programs run nicely already.
Friday, June 8, 2012
Hardware Inspection Part #1
Before even buying my Kindle Fire #1, I started to inspect the hardware and especially the main PCB on iFixIt. Because I love to know what is inside consumer electronics, I also love iFixIt! Of course, it can't make up for the experience and joy of opening and analyzing the device yourself and attaching a digital storage oscilloscope everywhere you like to. But it was a good start for me also here.
This is what I learned from there:
This is what I learned from there:
- The WLAN companion chip (from the WL127x series) uses just TI's WiLink WLAN IP core and not all 3 for WLAN, BT and GPS. Actually, there are 4 if you include FM. So no need to invest time into finding out the hard way by trying to get a linux driver working blindly.
- Although iFixIt missed to mention it, the Kindle Fire comes with an ambient light sensor. Right after my first kernel build, I immediately tried out all ambient light sensor drivers that I could find. None of them seems to work. Did Amazon remove it from the code? I payed for the sensor, I got it, so I've also the right to use it!
- Surrounding the Flash ROM there's a line of 40 soldering pads and a PCB imprint that hints at the shape of a ZIF socket. I suspect that on pre-production models Amazon either used that for a larger, exchangeable Flash module or the JTAG interface. Or for both :-)
Subscribe to:
Posts (Atom)