The Pixel C: Open, but not-so-open. A rant from a developer perspective.

Search This thread

brando56894

Senior Member
Dec 16, 2010
1,881
257
Jersey City
Wow I knew this thing was a pain in the ass for you to dev on since I've been following your root/kernel work but I didn't know that it had an EC with it's own processor and OS, that's crazy! I was thinking what you and the other poster said above, and I'm sure in due time someone will compile ChromeOS to run on this baby.

there have been a couple stories written mid last year that google wanted to phase out chromeOS and someway merge it with android, then late last year stories that no, that is really not the case google is gonna continue to develop both OS's. assuming that the merge thing was really going on inside google maybe that had something to do with the pixel c mess.

That's exactly what I'm thinking, there are a lot of things that point to it (Sundar moving from the ChromeOS team to Android, stories stating that it will happen sometime in the near future, the gigantic Chrome Android statue at the GooglePlex). They initially developed this either as a pure ChromeOS device or it was supposed to be (and most likely will be) the first device to run the merger of the two. I'm thinking something like tablet mode running the Android UI when it's not docked and when it is, it uses the ChromeOS UI, or maybe something far similar which is already possible in some forms on ChromeOS: it was meant to be a ChromeOS device that ran Android apps but the UX sucked since ChromeOS isn't meant for touchscreen use so they scrapped it and went with Android until all the kinks could be worked out. I'm going to assume the next major Android release for the Pixel C will tell us why the device was built this way, considering that the Reddit AMA about the Pixel barely mentioned anything other than "Wait for the next Android release! We have a lot of interesting things coming!". They clearly want us to mess with it since they provided us with factory images and an unlockable bootloader so we're probably the Guinea Pigs that will find all the issues so that Google can focus on fixing it and merging the two codebases together. I/O 2016 is only a few months away! :D
 
Last edited:

feng2345

Member
Feb 29, 2016
5
1
I also met some problem when worked with pixel c. I want to disassemble the boot.img as a android boot.img, but failed. When I looked into it with hexedit, I found it is a CHROMEOS image!!! A android kernel was in it, but not as a android image format. I think, I need to read the chromeos image format first in order to extract it, do you also does it in the same way?
 

cheep5k8

Senior Member
Sep 26, 2012
587
1,067
Berlin
I also met some problem when worked with pixel c. I want to disassemble the boot.img as a android boot.img, but failed. When I looked into it with hexedit, I found it is a CHROMEOS image!!! A android kernel was in it, but not as a android image format. I think, I need to read the chromeos image format first in order to extract it, do you also does it in the same way?

Yep. Actually the image is based on the arm64 FIT boot image format. It's really a bit complicated, but if you have any more questions just ask.
 

feng2345

Member
Feb 29, 2016
5
1
Thank you for your reply.
I have extracted kallsyms and disassembler from boot.img of pixel c. Very intresting.

I have another question, where can I get the official source code of pixel c? The code in website github.com/md5555/android_kernel_google_dragon/ seems very different from NVIDIA l4t release(developer.nvidia.com/embedded/linux-tegra-archive). Which one is used by google pixel c team?

Thanks
 

CrazyPeter

Senior Member
Sep 1, 2010
1,256
466
Wow I knew this thing was a pain in the ass for you to dev on since I've been following your root/kernel work but I didn't know that it had an EC with it's own processor and OS, that's crazy! I was thinking what you and the other poster said above, and I'm sure in due time someone will compile ChromeOS to run on this baby.



That's exactly what I'm thinking, there are a lot of things that point to it (Sundar moving from the ChromeOS team to Android, stories stating that it will happen sometime in the near future, the gigantic Chrome Android statue at the GooglePlex). They initially developed this either as a pure ChromeOS device or it was supposed to be (and most likely will be) the first device to run the merger of the two. I'm thinking something like tablet mode running the Android UI when it's not docked and when it is, it uses the ChromeOS UI, or maybe something far similar which is already possible in some forms on ChromeOS: it was meant to be a ChromeOS device that ran Android apps but the UX sucked since ChromeOS isn't meant for touchscreen use so they scrapped it and went with Android until all the kinks could be worked out. I'm going to assume the next major Android release for the Pixel C will tell us why the device was built this way, considering that the Reddit AMA about the Pixel barely mentioned anything other than "Wait for the next Android release! We have a lot of interesting things coming!". They clearly want us to mess with it since they provided us with factory images and an unlockable bootloader so we're probably the Guinea Pigs that will find all the issues so that Google can focus on fixing it and merging the two codebases together. I/O 2016 is only a few months away! :D
ChromeOS devices are selling really well, particularly in the education sector, they vastly outsell iPads. Android is by far the dominant tablet and mobile OS. Any merge could mess up either or both winning formulas.

I think the pixel C story will become clear eventually, the the hardware was ready long before the software was. I think we are going to see Android become a much better desktop laptop OS and it does smart stuff when the keyboard is attached, the OS window manager makes it behave like A laptop, when it's undocked from the keyboard, Android behaves like a tablet again.

Right now, using the keyboard feels awkward, as occasionally you have to use the touchscreen too...
 
Last edited:
  • Like
Reactions: rubene66

feng2345

Member
Feb 29, 2016
5
1
Hi,
I got a 0day on pixel c. I want to exploit it. But it is difficult to debug, so I want to add some debug info in the kernel. The problem is when I repacked the boot.img, the kernel can't boot up. Is there some instructions to build the kernel and repack it in a right way?

Thank you.
 
  • Like
Reactions: rubene66

Nex5x

Member
Feb 29, 2016
18
5
** Update edit: I got my pixel c to boot but still have not fixed the backlight and touchscreen is not working. I know the EC controls the backlight, at least a chromium os dev page said it does in devices generally. Tried flasing Marshmallow to go back to the original android version, not fixed and only booting to recovery. Will try 8.1.0 again and sideload root, hoping maybe there is some chance twrp will be more effective in doing a clean install. Not sure what else to do. Wish I could flash the EC with a USB SuzyQable debug cable.




OP or if there happens to be anyone else.... I read much of the Chromium OS Dev group pages and everything here. I really don't like this convoluted EC ChromeOS boot and peripheral management. My screen backlight stopped working and after flashing stock 8.1.0 and 7.1.2, I actually opened up my Pixel C to reseat the flex cables. It won't even turn on as temporaeily disconnecting the battery did something to where the EC doesnt complete it's boot or possibly verifications. It just pulses the rainbow bar twice before abruptly shutting of the light. I tried the battery reset method Google cites for charging issues (disconnect cable while holding power + volume up and down then releasing and waiting 30 sec before charging it for 5 min).

I am thinking that the problem with the EC/ AP (android) combination is the EC and android get out of sync somehow on the rewritable portion of the EC. The EC controls the backlight and probably the Synaptics capacitive touch controller. For now I just need it to boot again. If I touch the metal case quickly during the two rainbow pulses it shows my battery status correctly. The development powerpoints say there is a Battery Cutoff/Shipping state but doesn't mention how to boot normally after the battery being briefly disconnected. Unfortunately it seems their custom servo debug board is needed to diagnose and flash the EC firmware, which would not be standard.
 
Last edited:

therevan

New member
Nov 11, 2009
1
0
@cheep5k8 Long story short, I managed to remove the front-facing camera ribbon inside my Pixel C, and re-attach the screen, with everything working.

Long shot, but now that I've done this, would it be ... fun? ... to try and built/install ChromeOS on this device? If not fun, possible? :)

Wanted to offer myself up as a test case, if you wanted to see if it was possible to wipe out the storage and load something neat on.
 

Alxoom33

Senior Member
May 18, 2011
5,128
1,836
New York
www.sack-ip.com
@cheep5k8 Long story short, I managed to remove the front-facing camera ribbon inside my Pixel C, and re-attach the screen, with everything working.



Long shot, but now that I've done this, would it be ... fun? ... to try and built/install ChromeOS on this device? If not fun, possible? :)



Wanted to offer myself up as a test case, if you wanted to see if it was possible to wipe out the storage and load something neat on.
About 6 months or so ago, I looked into this question and contacted several Chrome OS developers about potentially porting Chrome OS to the Pixel C. The response was not positive. Apparently, if it was doable, it was extremely difficult and would involve significant reprogramming.

Sent from my Pixel 2 XL using Tapatalk
 

Top Liked Posts

  • There are no posts matching your filters.
  • 31
    First off, let me make clear that this post is written purely from a developer perspective. As a user, I love the Pixel C despite its shortcomings, use it all the time (even if mostly just for web browsing, at the moment at least).

    But as an Android developer (both OS and apps), the device makes it really hard to love it.

    The Pixel C is, hardware-wise, and firmware-wise, a ChromeOS device. Not maybe, not used to be, but fact. It starts with using coreboot+depthcharge as the bootloader that only on the very top of everything boots Android, and goes over to the ChromeOS EC (Embedded Controller).

    And it is this embedded controller, combined with the Tegra X1 chipset, that I have the most gripes with.

    What is the EC? The EC is, somewhat contrary to its naming, not a "dumb" controller, but actually a fully-fledged system inside the Pixel C. It has its own CPU (a Cortex A7) and its own operating system (which is much much smaller than the OS the device actually runs, in this case Android).

    The EC does basic things like partially controlling the boot sequence, and having direct control over auxilliary hardware like the device's sensors. That means that the OS has to rely on communication with the EC to make use of the sensors, and that is exactly how it is implemented in the Pixel C.

    So what is my trouble now, finally, you might be wondering at this point.

    Maybe some of you have noticed that over the course of the past weeks I tried to develop Double Tap to Wake for the Pixel C.

    My initial approach was the same as on other devices: make sure the touchscreen still receives power and handles events, even if the screen is turned off. Then listen for gestures (like a double tap), and if a gesture is recognized, activate the device.

    This didn't work out, because the Tegra X1 chipset is extremely strict when it comes to power management. Similar to the EC, you don't have direct access to the PMU (Power Management Unit), but rather need to go through the Tegra's PMC (Power Management Control).

    Basically, while I've succeeded in keeping the touch screen awake after the device is suspended, it amounts to nothing since the Tegra can only be awoken by specific events when in LP0 state (Low Power 0). These events are already pre-determined by the firmware and can be hooked into through the DTB (Device Tree Blob) which contains hooks and information for the various kernel subsystems.

    It does so for the PMC as well, but since the events are already hardcoded, there is no way to wake the device from suspend on a touchscreen event in a useful way, or at least not with the Linux kernel 3.18 used in the Pixel C.

    So double tap to wake works, until the system goes into LP0 suspend, which happens very quickly after you turn off the screen if everything works well (no wakelocks or wake interrupts).

    I gave up on that, and decided to implement double tap to wake through the mechanism the Pixel C already makes use of, as we all know: if you double tap on the back, OR the front, the Lightbar will show you the battery level.

    It turns out that this feature is controlled by the EC, but since there is only access to the sensors via the EC, it is the EC and only the EC that can propagate the event to the host system, and possibly wake it up from suspend in case of a double tap.

    I had, again, everything working: I've created a small framework overlay APK so you can enable wake settings in Android Settings, modified power.dragon and sensors.dragon (two Android modules that interact with various subsystems in order to control the devices state, and to read sensors, respectively).

    Double Tap to Wake using the sensor worked!

    Until... the system goes into LP0 again. It was very frustrating, and became even more so once I read the EC source code and realized that the event simply isn't hooked up into the host system on purpose, in order to enable the Lightbar tap functionality.

    Now, I'm not saying that this all is deliberately created in such a way as to make development hard for the device. But none the less, it is.

    In order to make this work (I don't see much of a chance for DT2W using the screen), I will have to compile my own modified EC firmware, flash it onto the Pixel C, hoping I didn't make some grave mistake that will blow my Pixel C up in smoke, something that I wouldn't have to do on a usual Android device.

    As you can see, all this is becoming a little convoluted, hairy, and dangerous. It's akin to getting the mostly undocumented sourcecode for your Laptop's EFI BIOS, compiling it yourself, and then flashing it into your Laptop, hoping you compiled from the right version of the source code, you did everything right while flashing the new firmware, etc.

    The next problem is whether this, flashing your own EC firmware, is even possible at all things given. The Pixel C has, like all ChromeOS devices (I'm staying with my point here), a Write-Protect mechanism. In the Pixel's case it's not a screw, but it is the front camera flex.

    Only with the Write-Protect disabled you have full access to the device on a similar level which you would have on a normal Android device after unlocking the bootloader. But, in order to access it on the Pixel, you need to take off the screen. You'd have to heat-gun the front until the adhesive comes off, pry off the screen with bezel, disable the Write-Protect, and then somehow reassemble the Pixel.

    I bet at this point many will agree that it's all a bit extreme just in order to get a feature like Double Tap to Wake working.

    Still, I will be trying. But not today. And probably not tomorrow.

    Over and out.
    10
    Unless they can magically flash PURE Android on this, and get rid of all the junk that ties it to ChromeOS

    This is not going to happen. It would require very elaborate and extensive work on the firmware to make it appear like a true Android device, something that is not necessary for the device's first line of sale, and is sure as rain not going to happen just for the aftermarket. To be honest, they've already done a pretty good job at masquerading it as an Android device in the very short time frame they had, and it's still way problematic.

    Still, I feel, and I'm not really sure why, that we can fix at least some things wrong with this device, but it's so damn messy. I mean, why would you leave the Write-Protect enabled on a device that effectively runs Android, especially if it's impossible for normal users, and thus developers, to disable it. Who's going to take the screen apart just to have some features added? Probably only the most die-hard of developers, and sure as hell no casual users who just want to flash a ROM. Some input from the Nexus team would have been really appreciated here.

    I'm gonna try my best, but the past few weeks have been extremely frustrating. I just kinda want to enjoy the device for now, and that's just not possible once you start developing on an OS level beyond minor modifications to the kernel, so I'm taking a break, taking the device as it is (which is easier than I thought it would be, perhaps because in theory it is such a wonderful device), and focus on other things for the moment.
    3
    Aka the tablet doesn't know what it should be?

    The rush to change it to Android could also show us why it's such a buggy mess. they already said they were gonna launch it at Xmas so I wouldn't be surprised to hear that ti didn't get a proper QA acessment and was just pushed out when they got Android "stable" enough.

    The fact it's taken this long for even a statement from Google about the issues is ridiculous and why is it taking so long to fix?

    I've actually helped a volunteer at Google to debug the WiFi issue, since they knew of me and knew my device is rooted, so I was able to perform diagnostic tests from the side of the device.

    It seems to be very difficult to fix simply because it was, so far, not clear what exactly the reason for the WiFi issues is. It doesn't really seem like (only) a hardware issue with lost reception. The WiFi interface also massively drops packets/needs data retransmits, something is going wrong but it's not clear if that happens at the hardware level, the firmware level, or the kernel level.

    I also tried to diagnose and possibly fix the WiFi issue myself; so far, no luck.
    3
    well if the new update isn't released soon I may just suck it up and start trying out things to help.

    Thinking about it since fixes were pushed to the Chromoniumgit is this tablet always gonna contain stuff from ChromeOS?

    It can't not be a ChromeOS device. The entire board, basic hardware and firmware setup is built like a Chromebook. It has the Chrome EC, it starts up (boots) like a Chromebook, etc. This can't be realistically changed.

    The "only" things really different from a Chromebook are:

    - It is a touch-only device (there's the Chromebook Flip but it at least also has a keyboard)

    - The storage partition layout has been partially changed so that Android can deal with it

    and

    - Instead of, at the very end of the boot sequence, booting ChromeOS, it boots Android. But actually, this is the least spectacular and least intricate part about the Pixel C's nature (even though of course a complex matter from a pure Android point of view). Both ChromeOS and Android use a Linux kernel. I'm not even entirely sure whether the Pixel C kernel contains any greater Android-specific adaptations that make it different from a ChromeOS kernel, aside from having a slightly different build configuration. When the Android kernel finally boots (from inside a ChromeOS boot image, may I remind you), it just expects to find a specific partition layout, which is there, and not the biggest problem to arrange. And after that, it just needs the right drivers, and it runs.

    So, yes, the Pixel C is very much a ChromeOS device.. a Chromebook without keyboard, if you will, even if there are some people adamantly claiming the opposite. It just happens to run Android.
    1
    Aka the tablet doesn't know what it should be?

    The rush to change it to Android could also show us why it's such a buggy mess. they already said they were gonna launch it at Xmas so I wouldn't be surprised to hear that ti didn't get a proper QA acessment and was just pushed out when they got Android "stable" enough.

    The fact it's taken this long for even a statement from Google about the issues is ridiculous and why is it taking so long to fix?