Related
Well, it only took 2 years lol!
What is Kexec?
Kexec (kernel-execute) is a function of the Linux kernel that allows it to act as a bootloader to boot other kernels. Unfortunately, the standard implementation of kexec doesn't work quite right on most ARM devices due to poor driver support for hardware resets. The workaround is kexec-hardboot, a patch set that allows a kernel to be staged in RAM before performing an actual hardware reset through the phone's bootloader. Upon reboot the kexec-supporting kernel will check the magic location in RAM to see if a previously stored kernel is available, and if so, it will transfer execution to that kernel instead of booting itself.
Why use Kexec
It's a second-stage bootloader. The standard Android bootloader only allows two kernels to be installed at once - boot and recovery. This means that if you want a working recovery, you're only allowed one real OS kernel. If you want to dual-boot (or tri-boot or more) you're screwed. Kexec provides an answer to this. By replacing the boot kernel, kexec (with the kexecboot GUI) acts as a "second stage bootloader" allowing you to boot any number of kernels from any available storage devices. For instance, you have kexecboot in your boot partition and you can keep a kernel for Android installed in your Android system partition as well as an Ubuntu kernel and root filesystem on your SD card and be able to switch between Android and Ubuntu at boot time.
What is kexecboot
http://imgur.com/4GYomKX
Kexecboot is a graphical front-end for kexec. I have modified it to work with the kexec-hardboot patches. It scans all available storage devices for a boot.cfg file in which you define kernels, ramdisks, and kernel commandlines. You control it using volume up and down to move cursor, power to select.
Download
Get it here: https://mega.co.nz/#F!0ct3EaTD!wHWnGo1M_2smyKdzGMIYmw
The code
Kernel builder: https://github.com/CalcProgrammer1/kernel_quincyatt_kexec
This repository contains all the things you need to build a flashable kexecboot/kexec-hardboot enabled kernel image. It contains the ramdisk with the kexecboot binary and a script to package a flashable zip file. Included as submodules are the kernel source itself (kexec-hardboot branch, required to build the image) and the kexecboot source (optional, not used by default as you must build it using an ARM system, a pre-built binary is included if you don't want to build your own). The kernel source includes a defconfig called kexec_quincyatt_defconfig that sets the required config options for building a kexec-hardboot kernel.
Kexecboot Configuration File
Kexecboot replaces your boot kernel, so when you power up your phone it will go straight to the Kexecboot screen. The issue is now to provide kernels for kexecboot to boot into. This requires some work on your part, as you will have to store the kernel files (zImage and initrd) in a partition and write a configuration file to tell kexecboot where they are. This configuration file may contain multiple kernels, allowing you to have several different kernels available for the same OS or multiple OSes entirely. If you're coming from an Android system that distributes their kernel as a boot.img, you can use the abootimg program to extract it into a separate zImage and initrd.img binary.
The configuration file must be located on the path /boot/boot.cfg. This is relative to whatever partition/disk you are on, so for instance if you're setting up Android to boot from kexecboot, you would put your configuration file in /system/boot/boot.cfg (/data/boot/boot.cfg would work as well). You can also put a boot.cfg file on your SD card as long as you follow the /boot/boot.cfg path. Kexecboot automatically scans all available partitions for a boot.cfg file before it starts and builds a list of all available kernels across all detected boot.cfg files, so you may have Android in your /system partition and Debian on your SD card and both kernel lists will be shown together.
The Kexecboot web site provides a nice tutorial: http://kexecboot.org/documentation/how_to_write_config
The Note i717 bootloader passes a fairly long string of kernel arguments to the boot kernel. Since kexecboot overrides this for the kexec-booted kernel, you must provide this boot string in your boot.cfg file. Additionally, you may edit or add arguments to the command string here (such as setting console=tty0 instead of the default console=null so you can use the framebuffer console).
For example, here is my /system/boot/boot.cfg for CyanogenMod 11 (with kernel and initrd.img, extracted via abootimg, in /system/boot/)
Code:
# kexecboot configuration file
# CM11 default kernel
LABEL=CyanogenMod 11
KERNEL=/boot/zImage
INITRD=/boot/initrd.img
APPEND="androidboot.hardware=qcom usb_id_pin_rework=true no_console_suspend=true zcache [email protected] [email protected] sec_debug.reset_reason=0x1a2b3c00 pmem_sf_addr=0x7a000000 pmem_sf_size=0x6000000 console=null sec_debug.enable=0 sec_debug.enable_user=0 appsbark=0 msm_watchdog.enable=1 msm_watchdog.bark_time=30 msm_watchdog.bite_time=31 vmalloc=512m hw_rev=12 lpj=67702 androidboot.emmc=true androidboot.serialno=32c245ca androidboot.baseband=csfb"
I'm not sure how much of that you actually need, but you do need at least some of it because with an empty APPEND= it does not boot. You also do have to put the quotation marks around it or else parsing of one of the options will fail.
I'll admit limited understanding of what you're accomplishing here, but seems to me that this could lead to dual booting on the Note. Nice work.
Good luck.
Nice work! Thanks for the work you've done thus far. Unfortunately I have no way to help you out other than morale support! :highfive:
lactardjosh said:
I'll admit limited understanding of what you're accomplishing here, but seems to me that this could lead to dual booting on the Note. Nice work.
Good luck.
Click to expand...
Click to collapse
Pretty much what it comes down to, testing kernels and roms without having to flash into nand. I can't wait for dualbooting from Sd on the Note.
I have ORD , please help!!
My main goal here is native Linux, but if kexec works then you can boot custom Android dev kernels, native Linux kernels, other mobile OS'es, etc. The SGSIII team seems to have found some interesting kexec solutions for the Verizon SGSIII due to its locked bootloader. They've posted a good deal of kexec patches which I'm trying to bring to the Note, including a custom kexec-hardboot option that fully reboots the device into the new kernel (apparently to make sure the radio and such are working).
CalcProgrammer1 said:
My main goal here is native Linux, but if kexec works then you can boot custom Android dev kernels, native Linux kernels, other mobile OS'es, etc. The SGSIII team seems to have found some interesting kexec solutions for the Verizon SGSIII due to its locked bootloader. They've posted a good deal of kexec patches which I'm trying to bring to the Note, including a custom kexec-hardboot option that fully reboots the device into the new kernel (apparently to make sure the radio and such are working).
Click to expand...
Click to collapse
Wonderful, wonderful work!!! :thumbup::thumbup::thumbup:
Sent from my SAMSUNG-SGH-I717 using xda premium
Uh...It all sounded like this:
dual kernel (i'm gonna brick) kexec will allow (me to brick my phone).....with native linux applications ('im gonna brick my phone cause i'm stupid)....LOL
while i know what your doing, that in no way means i will ever understand it...LOL
But i will thank you in advance for what sounds like a sick mod for our notes...
Many thanks Dev !!!!
Kexec is actually (if done right) a good way *not* to brick your phone. To run kernels, you usually have to flash them to a restricted boot section of the memory, and if you flash all non-working kernels (to download, recovery, and main) then you have no way to use your phone, as it won't boot up. If you use kexec, your working kernel is safely stored on the boot partition and your development kernels can be wherever, and if it doesn't boot you can just hold down POWER to hard reboot into your good kernel.
The problem is that it doesn't seem to be working, I think I have the kexec support built properly but haven't been able to boot any kernels without it crashing.
CalcProgrammer1 said:
Kexec is actually (if done right) a good way *not* to brick your phone. To run kernels, you usually have to flash them to a restricted boot section of the memory, and if you flash all non-working kernels (to download, recovery, and main) then you have no way to use your phone, as it won't boot up. If you use kexec, your working kernel is safely stored on the boot partition and your development kernels can be wherever, and if it doesn't boot you can just hold down POWER to hard reboot into your good kernel.
The problem is that it doesn't seem to be working, I think I have the kexec support built properly but haven't been able to boot any kernels without it crashing.
Click to expand...
Click to collapse
I know you'll crack it ....
And when you do ....you'll be the galaxy note GOD !!!....LOL
your effort is much appreciated Sir ....even if I'm scared to use it , but will anyway ...lol
So I'm still confused as to why my kexec didn't work. I'm going to build a TouchPad kernel with it enabled and repeat the test on it, since I have a known-good kernel to boot against. I'll let you know how that goes.
Sent from my SAMSUNG-SGH-I717
Ok, so long-time-no-see but I'm reviving this post! Now that my Note 3 is happily running Cyanogenmod I have no urgent need for my Note 1 and can hack on it!
So far I haven't gotten kexec working, but I do have:
1. Kexecboot (graphical kexec frontend) is working, detects OS images appropriately
2. Framebuffer Console (text-mode display, USB OTG keyboard supported for interactive command line)
3. Overriding bootloader command line (to enable the fbconsole you need console=tty1 but the bootloader passes console=null)
4. Framebuffer console rotation (boot up in landscape or portrait, no way to switch without recompiling at the moment)
5. Most of kexec-hardboot ported from the HP TouchPad port, no clue if it's promising or not as so far it just crashes after a while of nothing
6. Ubuntu 13.04 (desktop edition) rootfs installed on SD card in a chroot, also taken from HP TouchPad
What I'm working on:
1. Kexec-hardboot port (needed to use kexec properly and boot kernels)
2. Fixing fbconsole glitching (framebuffer console displays garbled text that slowly clears up, no clue why...reading /dev/fb0 repeatedly clears up the display immediately and is a dirty hack that works well enough for testing)
3. Networking (either USB Ethernet or integrated WiFi, going to try backported brcmfmac driver)
4. Ubuntu (that's the long-term plan here)
5. Note 3 S800 port if I get everything figured out here
CalcProgrammer1 said:
Ok, so long-time-no-see but I'm reviving this post! Now that my Note 3 is happily running Cyanogenmod I have no urgent need for my Note 1 and can hack on it!
So far I haven't gotten kexec working, but I do have:
1. Kexecboot (graphical kexec frontend) is working, detects OS images appropriately
2. Framebuffer Console (text-mode display, USB OTG keyboard supported for interactive command line)
3. Overriding bootloader command line (to enable the fbconsole you need console=tty1 but the bootloader passes console=null)
4. Framebuffer console rotation (boot up in landscape or portrait, no way to switch without recompiling at the moment)
5. Most of kexec-hardboot ported from the HP TouchPad port, no clue if it's promising or not as so far it just crashes after a while of nothing
6. Ubuntu 13.04 (desktop edition) rootfs installed on SD card in a chroot, also taken from HP TouchPad
What I'm working on:
1. Kexec-hardboot port (needed to use kexec properly and boot kernels)
2. Fixing fbconsole glitching (framebuffer console displays garbled text that slowly clears up, no clue why...reading /dev/fb0 repeatedly clears up the display immediately and is a dirty hack that works well enough for testing)
3. Networking (either USB Ethernet or integrated WiFi, going to try backported brcmfmac driver)
4. Ubuntu (that's the long-term plan here)
5. Note 3 S800 port if I get everything figured out here
Click to expand...
Click to collapse
Long time in the making. Glad to see you're still at it. Hope you are able to get it working. Would be pretty cool. Good luck
If you can get this working up to kernel with freedreno I'd be all over working on getting Plasma Active onto this thing. I've missed having a real linux phone since my n900 died.
Got Bluetooth working from the command line!
Code:
# rfkill unblock all
# hciattach /dev/ttyHS0 any
# hcitool scan
It detected my Note 3 which I had set to visible! Hopefully I can pair a BT keyboard with this and lose the USB OTG dependency. Still working on figuring out WiFi, I have the brcmfmac driver from 3.13 backports compiled and loaded but the WiFi chip isn't being detected so the driver never creates an interface for it. The chip is a Broadcom BCM4330 WiFi/Bluetooth chip, and although both WiFi and Bluetooth share the same chip they use different interfaces to the SoC (UART for BT and SDIO for WiFi).
I plan on doing more research into getting the hardware working before I do any more work on kexec. It will be much easier to debug kexec I think knowing how to use WiFi/BT/USB/etc. The only hardware I'm not going to attempt at all is the modem as I don't use this device as a phone anymore and don't have a SIM card in it. That said, all the rmnetX entries that I think are modem interfaces show in ifconfig -a so maybe it is working.
My kernel source is here:
https://github.com/CalcProgrammer1/ubuntu-kernel-quincyatt
The kexec branch will have the kexec hardboot patches once I figure them out. I've also got a folder set up with a script to automatically build the kernel zImage, build the modules, build the backport driver modules, build the ramdisk from a ramdisk root folder, build the boot.img, and then package that up in a flashable .zip. I'll upload parts of this system as I complete them. I also have an Ubuntu rootfs on my external ext4 (or was it 3?) SD card that I ripped straight off my TouchPad. For now I'm just using a busybox shell in my ramdisk, dropping out of kexecboot into ash, setting up a chroot for the SD card, and chrooting into the Ubuntu rootfs that way. It's not ideal since Ubuntu's init process doesn't run but it does allow me to run all the installed utilites from said rootfs.
Edit: Rii Mini Bluetooth Keyboard paired and working! It was a roundabout way of doing so because dbus and upstart don't work in chroot so I had to use an old package called bluez-compat which provides the hidd command. I sideloaded the .deb with a flash drive. The command to pair a keyboard:
Code:
# hcitool scan
Scanning ...
XX:XX:XX:XX:XX:XX Bluetooth device name
# hidd --connect XX:XX:XX:XX:XX:XX &
XX:XX:XX:XX:XX:XX will be a hex value that is your keyboard's address. You find the address with the scan command and enter it on the hidd command to connect. I didn't have to enter any kind of passcode or pairing key, after running hidd it just started working.
http://imgur.com/2sV3TJr
I got it! I finally managed to get kexec hardboot working! I had to rewrite a bit of code in the kexecboot program to support kexec-hardboot better but I now have a bootloader that is working correctly, if slowly. I'll be posting my kernel source soon (it's a branch off of CyanogenMod's msm8660-common kernel) as well as my modifications to kexecboot itself. The kexec-tools binary I took out of the HP TouchPad port unmodified so I don't have the source for that (though it shouldn't be hard to find). I'll be looking into a Note 3 port soon, basically used the Note 1 as the guinea pig for this experiment.
If, somehow, you could adapt this for the ATT Mega 6.3 so as to bypass the locked tight bootloater.....you would be considered a hero!! People would build statues of you....write songs and name their children after you!!!!!?
Sent from my SM-T310 using XDA Premium 4 mobile app
Unfortunately you require an unlocked bootloader to install the kexecboot kernel. This isn't going to be a magic bullet for locked bootloaders. People have tried. For devices with exploitable bootloaders, it may help as you won't have to fake-sign kexec-booted kernels though.
CalcProgrammer1 said:
Unfortunately you require an unlocked bootloader to install the kexecboot kernel. This isn't going to be a magic bullet for locked bootloaders. People have tried. For devices with exploitable bootloaders, it may help as you won't have to fake-sign kexec-booted kernels though.
Click to expand...
Click to collapse
Grasping at straws, My Friend. Hoping that maybe this could be something like SafeStrap and could be d/l and installed as an APK.
Sent from my SAMSUNG-SGH-I527 using XDA Premium 4 mobile app
Got Debian booting! I also figured out how to get WiFi working from a non-Android Linux OS so this is definitely on track towards a full desktop OS!
To-do:
* X server, preferably with Freedreno GPU driver eventually
* Audio (q6.* firmware files and possibly an ALSA config)
* Startup scripts for Bluetooth initialization
* Figure out how to rotate the screen
dparrothead1 said:
If, somehow, you could adapt this for the ATT Mega 6.3 so as to bypass the locked tight bootloater.....you would be considered a hero!! People would build statues of you....write songs and name their children after you!!!!!?
Sent from my SM-T310 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I wont be having anymore children to name, but I can do a dog. He is too stoopid to know the difference. I can say aluminum foil and he will come running.
Sent from my SAMSUNG-SGH-I527 using XDA Free mobile app
UPDATE: See second post for initial downloads of AOSP, CM , Arndale and Linaro/Arndale builds. These are very much a work in progress and may not even work. I am putting them forth for testing for the dev community to try out on their chromebooks.
These builds will be based on the latest JB builds. There is still alot of work to be done here. The AOSP builds initially have been put up. The other builds will go up as they are completed. I am working on the documentation for putting this together as a repeatable process is doable. In time there will be an installer and other goodies, but for now this will just be a very vanilla and manual process.
My goal is to get a working port of JB on the Samsung Chromebook. There has been no significant work on this front AFAIK. So I am taking it on myself to learn and try this out. Any community input would be helpful in making this work. I am fairly n00b at this but am looking to make this work.
I found some promising information. I might be able to build this using the binaries from arndaleboard which appears to mostly use the same hardware.
FYI for anyone experimenting to make this work please note that the following MUST be done for any chance of these root files to boot from SD.
SD/MMC boot
vold.fstab
* Change the sdcard0 and sdcard1 lines so that the first line is sdcard1 and the second is sdcard0.
fstab.arndale
* Change all references to mmcblk0px to mmcblk1px.
init.arndale.rc
* Change the 2 references to mmcblk0px to mmcblk1px.
mountd.conf
* Change the reference to mmcblk0 to mmcblk1
http://www.arndaleboard.org/wiki/index.php/Main_Page
http://forum.insignal.co.kr/viewtopic.php?f=6&t=62
http://forum.insignal.co.kr/viewtopic.php?f=6&t=63
Now that the rootfs part is addressed I am tackling the booting issues. Current uboot methods focus mainly on linux distro booting. Android appears to require its own ramdisk (which is in the links below) there will be some extra downloads such as a working uboot.
Once there are working versions of all the needed components working. An installer or installer script will be put together along with documentation. I may release this to a separate thread which I will post here.
Additional info on flashing the actual arndale. http://www.arndaleboard.org/wiki/ind...Flash_a_Device
Arndale is the base hardware also used on a Samsung series 3 Chromebook. Most if not all the components will work.
Additionally MANTA aka nexus 10 hardware is similarly identical and can be used with some success. I am working on compiling base builds based on CM10, AOSP, Linaro and Arndale's git.
Some more info on the bootloader
http://www.denx.de/wiki/U-Boot
http://www.chromium.org/chromium-os/...arm-chromebook
Im using this post to keep notes on what I find and build. I might edit some more to update as I find stuff. I will create a separate post if I have any success. I got two of these. I can live with bricking one if it happens. And I imagine there is a way to restore the system if needed. I figure I will figure that part out first. To avoid any mishaps and have a brick.
CREDITS: Musical_chairs for his invaluable input and resources he has linked in this post. I will update credits for other contributors once I get through the whole thread and credit all those obviously who build the original code these builds will be based on.
DISCLAIMER: For advanced users ONLY!! Not responsible if your chromebook gets bricked, struck by lightning or eaten by a pack of wild boars or attacked by crab people! Anything you do strongly recommended it be done on an SDcard to ensure easy rollbacks and no destruction of firmware.
Here are the first downloads of the rootfs and ramdisk (both of which are needed for a working android install on chromebook) These are based on AOSP. More files will be coming as I am compiling. Basic instructions on how to set up uboot will be posted above as well as how to properly flash an SDcard. This assumes you know how to get your chromebook into dev-mode. Please note this is strictly for anyone with android system experience. The system may not even boot properly at this point. This is pre-pre-alpha at this point. There is alot of work to do before it even comes close to being usable. But if you get it working, please make a DD image (instructions above) and post it for all to use and work from. FOSS means sharing and sharing means caring. This will speed up the work needed to make this work for all of us.
aosp-ramdisk.img
https://mega.co.nz/#!sZgVmIQY!M9ANXXEJYAWR0TlRxV_mC3CdEXkTKC_Tgr1PdOD0Hxo
aosp-rootfs.tar.bz2
https://mega.co.nz/#!ZNgAFYqR!HkXcLxead3Zgm7lNcUzjb0YlfzEbbogTL5CnZDuUtIA
arndale-kernel
https://mega.co.nz/#!gIQXVLRC!U_L0WSutAXdGzdqhFrlzD1ij750Q8lTlKwHVoC28C14
arndale-ramdisk.img.ub
https://mega.co.nz/#!RB4XBAjS!JtNgciYJrLL_TDmjXjnZkTouPKwAhva26b7U9zvBYA0
arndale-rootfs.tar.bz2
https://mega.co.nz/#!xJwBVALa!QnwJRjQzhC218tcjMtKnimKZE2kn73sGs8XgeC75fDU
I'm super excited that you're working on this Opieum. This would be absolute dream come true. I'd love to help out but I can't be a tester lol. After I get my next few paychecks I'd love to send a donation to you sir!
Im still working on it. Its a bit tricker than I thought to get it working. Not impossible tho. I just lack the experience and knowledge to get this up and running. I figured I could do it over the weekend lol. Humbling experience. Once I have something working that is moderatly usable I figure I will take some donations to support other types of chromebooks, for now tho I will just do this cause I want to get android working on the samsung chromebook series 3.
opieum said:
Im still working on it. Its a bit tricker than I thought to get it working. Not impossible tho. I just lack the experience and knowledge to get this up and running. I figured I could do it over the weekend lol. Humbling experience. Once I have something working that is moderatly usable I figure I will take some donations to support other types of chromebooks, for now tho I will just do this cause I want to get android working on the samsung chromebook series 3.
Click to expand...
Click to collapse
May want to wait for IO until after if Chrome and Android get close enough to jump from one to the other.
Also, I guess you could try and use the Cyanogen Mod port tool to try and get Android on it. It's what I used to try and get Ubuntu-Phone on my Nook. Nearly have it, but got the black screen of doom.
Thanks moocow, I appreciate the advice. I had not considered the Cyanogen tool. I know google IO is right around the corner but I want to see if I can get it working. Part of it is as much a technical exercise to see if I can do it as much as it is just doing it.
Do you have a link for this porting tool? I was looking for one. If its just porting from the git I guess I can do that too. I was just wondering if there was a specific tool do this with. I was not aware there actually was a tool.
I'm so excited someone is trying to make this work! I'm no dev, but I'd love to help in anyway. Subbing now.
http://wiki.cyanogenmod.org/w/Doc:_porting_intro
This might help also.
http://wiki.cyanogenmod.org/w/Development
Amazing! I wish you the best of luck on this
I've seen some great development for the ARM Chromebook over on the Linux side, so anything is possible
Hope your efforts will be fruitful
Thanks!
I'm excited to see some effort being put into this!
I don't think you need to worry about flashing procedures just yet, and I certainly would forget about messing with uboot until way later in the game. It's pretty easy to get a dual-boot setup on the chromebook, getting the files in place is way easier than it is on a typical Android device because you can write them to an sdcard from inside ChromeOS, then reboot to the sdcard. We can worry about booting Android from the internal storage later, shouldn't be too hard. And to do anything with uboot, you're going to need to physically disassemble the chromebook and remove the write protect screw/sticker, IMO it would be best to avoid that.
Maybe we should start by adapting this procedure, but putting an Android filesystem and kernel on the sdcard instead of Linux?
http://blogs.arm.com/software-enablement/848-running-linux-on-the-series-3-chromebook/
Thanks. I have been hitting wall after wall with u-boot so yea I am working on the dualboot method for now. That post is great! I had not seen it before. Bookmarked among many. Hopefully I can find the issues keeping me from making this work.
The first obstacle I am seeing is that while ChromeOS uses a pretty standard Linux kernel and no ramdisk (and that is what uboot will be looking for), Android uses a kernel and ramdisk on a /boot partition. I don't know enough about Android to know if it's possible to boot it with a different configuration, but I've got a hunch that if we're going to get Android to boot on this thing, we're going to need to do it a lot more like the Android x86 people do it than like a typical Android ROM.
Two exercises that I think will be very helpful here:
1. Install a Linux (Ubuntu, Debian, Arch, Fedora, whatever) on the sdcard of a chromebook without using a script like chrubuntu
2. Install Android x86 on a 'normal' computer.
I have almost done the first (I cheated and ended up using a script to install Ubuntu), the second I may eventually do if I can find the time.
...and like I said, I think the best approach here is going to be a x86 style Android installation, but with an arm build.
---------- Post added at 01:42 PM ---------- Previous post was at 01:27 PM ----------
...or maybe this is what we need - chainload uboot:
https://plus.google.com/117557107585466185396/posts/hVWc5EE9EK6
---------- Post added at 02:09 PM ---------- Previous post was at 01:42 PM ----------
Okay, this looks to be the official documentation on using nv-U-boot (chainloading uboot):
http://www.chromium.org/chromium-os...using-nv-u-boot-on-the-samsung-arm-chromebook
Upon further reading, I believe that this is the correct method:
1. Pack nv-U-boot as a signed kernel and dd it to a chromeos kernel partition.
2. nv-U-boot then boots Android using a typical Android boot command.
For the time being, I'm pretty sure it will be better to keep nv-U-boot and all the Android partitions on an sdcard, as it is no harder to boot from there than from the eMMc, and it's a whole lot safer to test stuff this way. Once we've got it working, we can repartition the eMMc and install everything there so it's faster and all that good stuff.
Bear in mind this is pretty much just academic at this point, I tried to chainload nv-U-boot but haven't actually gotten it to work. I'm pretty comfortable mucking around in Linux systems, but this uboot stuff is all new to me.
What I've done so far:
1. Set up partitions on my sdcard (including two kernel partitons) as per the first link I posted.
2. Got a working Lubuntu installation on the sdcard (cheated and used a chrubuntu-derived script).
3. Got a working Crouton (chrooted) Lubuntu setup on the internal storage (doesn't really apply here, though it comes in handy for some of the tools needed for manipulating files and stuff)
4. Tried the nv-U-boot image from opensuse:
http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM:/Contrib:/Chromebook/standard/armv7hl/
5. Tried the nv-U-boot image from the Chromium Projects:
http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv_uboot-snow.kpart.bz2
In both cases, the process is the same. Pack nv-U-boot as a signed kernel, something like this (both commands are run in a shell from within ChromeOS, in dev mode):
Code:
vbutil_kernel --pack newkernel --keyblock /usr/share/vboot/devkeys/kernel.keyblock --version 1 --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk --vmlinuz u-boot.img --arch arm
write it to the sdcard with dd, something like this (remember you can hose almost anything with dd if you point it at the wrong place, so use with care:
Code:
sudo dd if=newkernel of=/dev/mmcblk1p2
(this writes it to partiton 2 of my sdcard, partition 1 is my good Ubuntu kernel.)
I haven't seen nv-U-boot yet but I think I'm close.
musical_chairs said:
Upon further reading, I believe that this is the correct method:
1. Pack nv-U-boot as a signed kernel and dd it to a chromeos kernel partition.
2. nv-U-boot then boots Android using a typical Android boot command.
For the time being, I'm pretty sure it will be better to keep nv-U-boot and all the Android partitions on an sdcard, as it is no harder to boot from there than from the eMMc, and it's a whole lot safer to test stuff this way. Once we've got it working, we can repartition the eMMc and install everything there so it's faster and all that good stuff.
Bear in mind this is pretty much just academic at this point, I tried to chainload nv-U-boot but haven't actually gotten it to work. I'm pretty comfortable mucking around in Linux systems, but this uboot stuff is all new to me.
What I've done so far:
1. Set up partitions on my sdcard (including two kernel partitons) as per the first link I posted.
2. Got a working Lubuntu installation on the sdcard (cheated and used a chrubuntu-derived script).
3. Got a working Crouton (chrooted) Lubuntu setup on the internal storage (doesn't really apply here, though it comes in handy for some of the tools needed for manipulating files and stuff)
4. Tried the nv-U-boot image from opensuse:
http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM:/Contrib:/Chromebook/standard/armv7hl/
5. Tried the nv-U-boot image from the Chromium Projects:
http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv_uboot-snow.kpart.bz2
In both cases, the process is the same. Pack nv-U-boot as a signed kernel, something like this (both commands are run in a shell from within ChromeOS, in dev mode):
Code:
vbutil_kernel --pack newkernel --keyblock /usr/share/vboot/devkeys/kernel.keyblock --version 1 --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk --vmlinuz u-boot.img --arch arm
write it to the sdcard with dd, something like this (remember you can hose almost anything with dd if you point it at the wrong place, so use with care:
Code:
sudo dd if=newkernel of=/dev/mmcblk1p2
(this writes it to partiton 2 of my sdcard, partition 1 is my good Ubuntu kernel.)
I haven't seen nv-U-boot yet but I think I'm close.
Click to expand...
Click to collapse
Yea the u-boot stuff is real new to me. I have no issues either with linux its the bootloader stuff with android I am struggling with. I'm going to look at the arndale instructions as it uses similar hardware on how to load it from SDcard. The documentation there seems to show how to load the system. I already built and compiled the code from arndale seeing as it uses the exact specs needed. Since we have the ability to boot from SDcard on a chromebook this should be easily doable. The build will be the hard part. I am going to see what i can do with that method, I'm adapting from various sources. Ideally if I can come up with a simple image that can just be DDed over to a 32GB SD card that would be best for all to start and test with until a much easier method can be adapted. I had read elsewhere that the android method had been tried using the linux methods and it did not work. Hence why I havent looked as deeply into it. But I think at this point it seems like looking at this with a mixed methods might be the better approach. I'll post my results tomorrow as I am trying this out now.
UPDATE: I got some promising news. I am following this guide I have built android according to those instructions. http://www.arndaleboard.org/wiki/index.php/WiKi#How_to_Flash_a_Device (ignore the dipswitch references here as we got the ctrl-U option to boot and devmode)
The uboot install part is automated via a script which saves some time. Easy enough to break down the script to see how its done manually. The build will have 4.1.1 That said arndale provides pretty much all the tools to do this simpler. I think if we get this working then all we need to do is further automate the process OR provide an image with a simple script to image an SDcard with. Additionally I suspect (I have not confirmed) that the wifi and other components on the arndale are also the same on the chromebook.
Hmm, I wonder if the uboot from the arndale board will work on the chromebook? The chromebook's uboot doesn't have fastboot, and there's no way to interrupt it either (as in, hold down a key to access the uboot menu). BUT, if we put the arndale's uboot on the sdcard, as in, this:
http://www.arndaleboard.org/wiki/index.php/WiKi#Prepared_micro_SD.2FMMC_for_ARNDALE_bootable.
...that looks rather promising.
Yea that was the idea and portion I was looking at. I'm trying it out now to see if this will work.
I thought something similar might be done with Plop, the most awesomest boot loader in the world when Chrubuntu was first finding it's feet. Booting into a bootloader might be the answer for not just Android, but Windows 7.
But this is booting on ARM. So Win7 would not work here as there is no ARM capable version. The work now is being done for the Samsung Chromebook ARM version (series 3) which would also work on the Acer version that is also ARM based as well.
Nuh uh, Acer C7 is x86 based. RT can play on ARM, but a Chrome bootloader might be worth it.
You are correct sir on the Acer being intel. That being said. This project is to get android on the samsung chromebook (series 3) which is an arm EXYNOS 5xxx series CPU. The methods developed here would also likley apply to any other arm based books on the market.
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
lionclaw said:
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
Click to expand...
Click to collapse
Wayyyy out of my area of expertise, but here's my (completely novice) best guess.
>All Chromebooks are write-protected with a screw on the motherboard
>Putting a Chromebook in developer mode allows for some tinkering ie things like chroots, and on the asus flip, the ability to install apks from unknown sources.
>Unscrewing the write-protect screw allows for the ability to completely install a new operating system or dual boot setup.
>Maybe you need to do that before you're able to accomplish root access?
My other idea would be to try and figure out a way of doing a systemless root?
Also, total aside but since this is the only thread I've found on XDA about this device, I think chroots are theoretically possible now without the need to be in developer mode via Android apps (even without root on Android). Download the GIMP port from the Play Store to see what I'm talking about. Playing around with that for a few minutes really made me wish that it didn't use emulated mouse/keyboard in it's implementation. Also, it appears that apt-get is broken, but regardless it might interest someone out there looking for a project.
back from the dead, any progress on this?
I have been able to successfully root the Android image on my Asus Flip.
I built a blank image with dd in /usr/local, formatted it with mkfs, mounted it to a folder, mounted the original system.raw.img to a folder, copied the files across, placed *all* the SuperSU files listed as 'required' in the SuperSU update-binary in the relevant places in /system in my new image, set permissions & contexts for those files, edited arc-system-mount.conf and arc-ureadahead.conf to point to the new image and, finally, patched /etc/selinux/arc/policy/policy.30 with the SuperSU sepolicy patching tool in order to boot my rooted Android instance with selinux set to enforcing.
I have created a couple of scripts which more-or-less fully automate this procedure, which can be downloaded from nolirium.blogspot.com. Please feel free to download, open the scripts in a text editor to check them out, and try them out if you like. Only tested on Asus Flip, though.
I seem to be unable to post attachments at the moment so I will just add the descriptions here, I could probably post the entire scripts here too if anyone wants. Feel free to let me know what you think.
DESCRIPTIONS:
1-3.sh
Combines the first three scripts listed below.
01Makecontainer.sh
Creates an 900MB filesystem image in /usr/local/Android_Images, formats it, then copies Android system files therein.
02Editconf.sh
Modifies two system files: arc-system-mount.conf - changing the mount-as-read-only flag and replacing the Android system image location with a new location; and arc-ureadahead.conf - again replacing the Android system image location. Originals are renamed .old - copies of which are also placed in /usr/local/Backup.
03Androidroot.sh
Mounts the previously created Android filesystem image to a folder, and copies SuperSU files to the mounted image as specified in the SuperSU update-binary.
04SEpatch.sh
Copies an SELinux policy file found at /etc/selinux/arc/policy/policy.30 to the Downloads folder, opens an Android root shell for the SuperSU policy patching command to be entered, then copies the patched policy back to the original location. A copy of the original policy.30 is saved at /etc/selinux/arc/policy/policy.30.old and /usr/local/Backup/policy.30.old
Uninstall.sh
Removes the folder /usr/local/Android_Images and attempts to restore the modified system files arc-system-mount.conf and arc-ureadahead.conf.
ok so two questions, one do you think this would work on the Acer r13 convertable? and 2 where can I find the actual instructions/scripts
keithkaaos said:
ok so two questions, one do you think this would work on the Acer r13 convertable? and 2 where can I find the actual instructions/scripts
Click to expand...
Click to collapse
The R13 has a 64-bit Mediatek processor, right?
I have added a version for ARM64, but I haven't tested it.
You can find the instructions and scripts at nolirium.blogspot.com
ya, its a mediatek. and thanks ill go see if i can find it
---------- Post added at 03:31 AM ---------- Previous post was at 02:58 AM ----------
wow, ok. i can do this but im not sure i want to.. after reading the possible problems i may run into. Im going to be getting the G. Home in a couple weeks and i gotta keep things running smooth. This seems like going a tad too far then i need to. The other day i had action launcher going and it looked pretty damn good but i really want to try and get the action3.apk that i have put into the pri-app folder or whatever the chromebook uses i found the syst folder but cant access it. Im wondering if i make the machine writable it would work but im afraid of losing my updates, as long as i could do them manualy, i guess that would be cool. Also since im already going on... has anyone found a way to disable the dev boot screen without tinkering with the physical chromebook yet?
SuperSU on Chromebook
Hey there I love this post but unfortunately im on the mediatek (well not unfortunately cause i love it) but i do really want super su .. But i found this other post that i tried out but i am having a problem executing the scripts. When i go to run the first one, it says can not open "name of script" but the dev takes a pretty cool approach. Im still new to Chrome OS but thanks for the post and if you have any advice on executing scripts id love to hear it!! http://nolirium.blogspot.com/
I'm guessing the above post was moved from another thread...
Anyway, it turns out that zipping/unzipping the files in Chrome OS's file manager sets all the permissions to read-only. Apologies! sudo chmod+x *scriptname* should fix it...
Regarding OS updates, I actually haven't had a problem receiving auto-updates with software write-protect switched off; the main possible potential issue I could imagine arising from the procedure I outlined would involve restoring the original conf files if both sets of backups get deleted/overwritten. This seems unlikely, but in that case either manually editing the files to insert the original string (/opt/google/containers/android/system.raw.img), or doing a powerwash with forced update might be necessary in order to get the original Android container booting again.
I don't think anyone's found a way to shorten/disable the dev boot screen without removing the hardware write-protect screw - from what I've read, the flags are set in a part of the firmware which is essentially read-only unless the screw is removed. Perhaps at some point the Chrome OS devs will get fed up of reading reports from users whose relatives accidentally reset the device by pressing spacebar, and change the setup. Here's hoping.
Hey just jumpig in the thread right quick to see if these instructions are old or what-- got a chromebook pro and the notion of having to update a squashed filesystem every timeto install su seems like a pain..
Is there any kind of authoritative documentation/breakdown regarding what Chromeos is mounting where before I start breaking things? Also anyone happen to know if there's a write-protect screw anywhere in the chromebook plus/pro?
Other questions:
* adbd is running, but is not accessible from adb in the (linux) shell, which shows no devices. Do I need to access adb from another device (i'm short a usb c cable right now) or can I use adb (which is there!) on the chrome side to access adbd on the android side?
* Anyone know if adb via tcp/ip is available? Don't see it in the android settings.
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
I'll attach them to this post in case anyone wants to take a look. There's a readme in the zip, some more details can also be found here and below
EDIT: Fixed the SE Linux issue occurring with the previous version I uploaded (it was launching daemonsu from u:r:init:s0 instead of u:r:supersu:s0).
Anyone considering giving them a spin should bear in mind that the method does involve creating a fairly large file on the device as a rooted copy of the android rootfs. (1GB for arm, 1.4GB for Intel). There's a readme in the zip but the other couple of important points are that:
a) The SuperSU 2.82 SR1 zip also needs to be downloaded and extracted to ~/Downloads on the Chromebook.
b) Rootfs verification needs to be off. The command to force this is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --force --partitions $(( $(rootdev -s | sed -r 's/.*(.)$/\1/') - 1))
or the regular command to do it is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
c) If, subsequent to running the scripts, there's a problem loading Android apps (e.g. after a powerwash or failed install), the command to restore the original rootfs image is:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Hey this is a great response.. thanks!
Nolirum said:
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
Click to expand...
Click to collapse
verity
Yeah playing with it now, I'm looking at these /etc/init/arc-*-conf files... I see that the /dev/loop# files are being set up... (more below)
Nolirum said:
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
Click to expand...
Click to collapse
Sorry not sure what you mean by "hybrid systemless root style setup"? I take it you're modifying the startup script and replaced the squashfs file in /opt... my concern about doing it was whether they were implementing some kind of dm-verity equivalent to the squashfs file to make sure it hasn't been tampered with (say, by adding /sbin/su or whatever) or whether it's safe to replace that file.. Sounds like you're saying it is? (update: I guess that's what rootfs verification does, and we can turn it off....)
Also you mean arc-setup.conf:
env ANDROID_DEBUGGABLE = 0
right?
Nolirum said:
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
Click to expand...
Click to collapse
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Nolirum said:
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Click to expand...
Click to collapse
Heh.. not gonna be me..
Nolirum said:
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
Click to expand...
Click to collapse
Cool-- adb connect 100.115.92.2 does indeed work I was gonna use netcat to open port 5555 in chromeos and pipe it through, but looks like nc isn't here and I'm not yet ready to start changing the FS..though probably will be soon... btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example... would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?
It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default witho no UI to turn it off.. and it's inaccessible from outside.. i wonder if there's an easy way to change the bridge to share the same IP as the actual interface...
Final thought-- I'd love to build that system image myself soup-to-nuts, but I can't find any "caroline" device tree set up... do you or anyone else happen to know if there's a standalone AOSP device tree for the chromebooks? It would be cool to have a mashup AOSP/lineageos if such a think could be possible-- I'm guessing chromiumos is just taking the android tree, building it and then adding it into their build... I Haven't build chromiumos for many years now so I can't even begin to imagine how this android build integrates with the whole emerge thing they had going.. but I bet it takes a while
Nolirum said:
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
Click to expand...
Click to collapse
Cool I'll take a look at these scripts.
So I haven't yet run the scripts-- just looking through them-- I noticed the section starting:
if [ -e /etc/init/arc-setup-env ]; then
echo "Copying /etc/init/arc-setup-env to /usr/local/Backup"
This doesn't exist on the x86 CB Pro. There's an arc-setup.conf that sets up the environment variables though. It sets WRITABLE_MOUNT to 0, but then so does arc-system-mount.conf
Not sure if these are different between x86 and ARM or if it's just in the latest update.. but figured I'd let you know. Wanna throw thse scripts up on github somewhere? (Or I can do it) and we can maybe look at keeping them up to date and/or standardizing them? It wouldn't be hard to determine if it's running on ARM or x86_64 (uname -i for example)..
fattire said:
So I haven't yet run the scripts-- just looking through them-- I noticed the section starting:
if [ -e /etc/init/arc-setup-env ]; then
echo "Copying /etc/init/arc-setup-env to /usr/local/Backup"
This doesn't exist on the x86 CB Pro. There's an arc-setup.conf that sets up the environment variables though. It sets WRITABLE_MOUNT to 0, but then so does arc-system-mount.conf
Not sure if these are different between x86 and ARM or if it's just in the latest update.. but figured I'd let you know. Wanna throw thse scripts up on github somewhere? (Or I can do it) and we can maybe look at keeping them up to date and/or standardizing them? It wouldn't be hard to determine if it's running on ARM or x86_64 (uname -i for example)..
Click to expand...
Click to collapse
Oh, the arc-setup-env thing is intentional. There does appear to be another issue with the x86 version though. I've written up a detailed response to your previous post; it's in a text file at the moment so I'll copy it over and format it for posting here with quotes etc now - should only take a few minutes. Yeah, sticking them on github might be a good idea; I've been meaning to create an account over there anyway.
Yeah, so... Regarding the scripts, since I've put them up here for people to download - I should mention that the first person to test them (aside from me) has reported that something's not working right (I'm waiting for confirmation but I think he tried out the x86 version). It's likely either an error on my part when copying across from my Arm version, or perhaps something not working right with conditionals, meant to deal with the various OS versions ('if; then' statements, I mean). Once I find out more, I'll edit my earlier post...
fattire said:
Sorry not sure what you mean by "hybrid systemless root style setup"? I take it you're modifying the startup script and replaced the squashfs file in /opt... my concern about doing it was whether they were implementing some kind of dm-verity equivalent to the squashfs file to make sure it hasn't been tampered with (say, by adding /sbin/su or whatever) or whether it's safe to replace that file.. Sounds like you're saying it is?
Click to expand...
Click to collapse
Oh, sorry for being a bit vague - I just mean perhaps implementing a kind of systemless root à la Magisk/SuperSU (from what I understand of how these work) - avoiding the need to actually replace files in /system. Since I'm mainly just using su for the privileges rather than actually wanting to write to /system, I had the idea that perhaps a sort of overlay on e.g. xbin and a few other locations, rather than actually rebuilding the whole of /system, might be an interesting approach....
Yep, I've been replacing /opt/google/containers/android/system.raw.img with a symlink to my modified image lately. Works fine... I think they've been focused on just getting the apps working properly, maybe something like dm-verity is still to come.
Although, one of the cool things with Chromebooks IMO is that once the Developer Mode (virtual) switch has been flipped, the system's pretty open to being hacked around with. I think a large part of the much-trumpeted "security" of the system is thanks to the regular mode/Dev mode feature, once in Dev Mode with verified boot disabled on the rootfs, we can pretty much do what we want (I like the message that comes up in the shell when entering the first command I posted under the spoiler - it literally says "YOU ARE ON YOUR OWN!").
So yeah, with Dev Mode switched off, verified boot switched on, we can't even get into the shell (just the walled-off 'crosh' prompt), making the system indeed rather secure (but, for some of us, rather limited).
fattire said:
Also you mean arc-setup.conf:
env ANDROID_DEBUGGABLE = 0
right?
Click to expand...
Click to collapse
That's what I mean by a moving target, lol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61. Problems with being on the more 'bleeding edge' channels include:
#Sometimes stuff gets broken as they commit experimental changes.
#Any updates sometimes overwrite rootfs customizations; the higher the channel - the more frequent the updates occur.
#Some of the stuff that gets updated, may later get reverted.
And so on...
fattire said:
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Click to expand...
Click to collapse
Yeah you'd think so. Honestly, the more I use CrOS the more it seems like a (very polished) work-in-progress to me. Though, I guess most modern OSs are also works-in-progress though. (I don't mean the former statement in a critical way; I'm very happy that new features keep getting added to the OS - Android app support being a perfect case in point, that was a lovely surprise, greatly extending the functionality of my Chromebook).
fattire said:
Cool-- adb connect 100.115.92.2 does indeed work I was gonna use netcat to open port 5555 in chromeos and pipe it through, but looks like nc isn't here and I'm not yet ready to start changing the FS..though probably will be soon...
Click to expand...
Click to collapse
Netcat's not there but socat, which I haven't any experience with but have seen described as a "more advanced version of netcat", is listed in /etc/portage/make.profile/package.installable, meaning that adding it to CrOS is supported, and as simple as:
Code:
sudo su -
dev_install #(sets up portage in /usr/local)
emerge socat
I tried socat out and it seems to work, might be interesting to play around with.
fattire said:
btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example...
Click to expand...
Click to collapse
Theres a question. I forget some of the exact details now (gleaned from browsing the developer mailing lists and the documentation on chromium.org), but from what I do remember and my experiences tinkering, I can say:
The auto-update model uses kernel/rootfs pairs, e.g. at the moment my device is booting from partition 2 (KERN-A) with the rootfs being partition 3 (ROOTFS-B). My understanding is that with the next OS update pushed to my device, CrOS will download the deltas of the files to be changed, and apply the changes to partitions 4 and 5 (KERN-B and ROOTS-B), setting new kernel GPT flags (priority=, tries=, successful=), which will, post-reboot, let the BIOS know that 4 and 5 will form the new working kernel/rootfs pair. Then the following update will do the same, but with partitions 2 and 3, and so on and so forth, alternating pairs each time. It's a pretty nifty system, and I think something similar might be happening with new Android devices from version O onward (?).
So partitions 2,3,4,5 are fair game for being overwritten (from the perspective of the CrOS updater program). Partition 1, the 'stateful partition') is a bit special, in addition to a big old encrypted file containing all of the userdata (/home/chronos/ dir?), it also has some extra dirs which get overlaid on the rootfs at boot. If you have a look in /mnt/stateful/, there should also be a dir called 'dev_image', which (on a device in Dev mode) gets mounted up over /usr/local/ at boot. As I mentioned above, if you do
Code:
sudo su -
dev_install
you can then emerge anything listed in /etc/portage/make.profile/package.installable (not a great deal of stuff admittedly, compared to Gentoo), which gets installed to subdirs in /usr/local/. So I think stuff in partition 1; /mnt/stateful/, should be safe from being overwritten with an OS update. I think crouton chroots get put there by default.
Most of the other partitions don't really get used, and shouldn't get touched by the updater, here's a design doc on the disk format, and here's a Reddit post (from a Google/Chromium employee) mentioning dual booting from partitions 6 and 7.
fattire said:
would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?
Click to expand...
Click to collapse
It's not too hard to mess up the system and get it into an unbootable state, lol. The "powerwash" just seems to remove user data, mainly. If you change up (the contents of) some files in /etc, or /opt, for example, then powerwash, normally they won't get restored to their original state (unless you also change release channel).
But, as long as the write-protect screw's not been removed and the original BIOS overwritten, it's always possible to make a recovery USB in Chrome's Recovery Utility on another device, and then restore the entire disk image fresh (this does overwrite all partitions). Another thing that I did was make a usb to boot into Kali; I was experimenting with the cgpt flags on my internal drive and got it into an unbootable state, but was still able to boot into Kali with Ctrl+U, and restore the flags manually from there. (To successfully boot from USB, it was essential to have previously run the enable_dev_usb_boot or crossystem dev_boot_usb=1 command in CrOS). I understand also that the BIOS type varies with device release date and CPU architecture, and that Intel devices may have some extra potential BIOS options ('legacy boot').
fattire said:
It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default with no UI to turn it off.. and it's inaccessible from outside.. i wonder if there's an easy way to change the bridge to share the same IP as the actual interface...
Click to expand...
Click to collapse
I think I saw something related to this on the bug tracker. If I come across any info, I'll let you know...
fattire said:
Final thought-- I'd love to build that system image myself soup-to-nuts, but I can't find any "caroline" device tree set up... do you or anyone else happen to know if there's a standalone AOSP device tree for the chromebooks? It would be cool to have a mashup AOSP/lineageos if such a think could be possible-- I'm guessing chromiumos is just taking the android tree, building it and then adding it into their build... I Haven't build chromiumos for many years now so I can't even begin to imagine how this android build integrates with the whole emerge thing they had going.. but I bet it takes a while
Click to expand...
Click to collapse
Yeah, I haven't built Chromium OS or anything, but apparently, there's an option to create a 'private' overlay for the build, which doesn't get synced with the public stuff.
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
"That article is a little misleading in terms of open source. While the wayland-server and services that communicate with the ARC++ container are open source, the actual ARC++ container is not."
Perhaps they're waiting to see how similar implementations of Android within a larger Linux setup (e.g. Anbox) fare.
There doesn't seem to be too much that differs from AOSP in the ARC++ container - a few binaries and bits and pieces linking the hardware to the container (e.g. the camera etc), maybe some stuff related to running in a container with the graphics being piped out to Wayland?, and so on.
Oh, I was searching the bug tracker for something else, and just saw this (quoted below). Looks like it might be possible to run AOSP based images on CrOS soon!
arc: Implement android settings link for AOSP image
Reported by [email protected], Today (72 minutes ago)
Status: Started
Pri: 1
Type: Bug
M-60
When ARC started without the Play Store support there is no way for user to activate Android settings. We need implement corresponded section that has
Title: Android settings:
Link: Manage android preferences:
Inner bug: b/62945384
Click to expand...
Click to collapse
Great response! I read it once and I'll read it again in more detail then will probably have questions For whatever it may be worth, my only experience with chromiumos was building the whole thing maybe 4 years ago for my original 2011 Samsung "snow" Chromebook-- and making a bootable USB (or was it an SDcard?) to run it on (with a modified firmware that did... something I can't remember.. i think it was basically a stripped down uboot and I remember adding a simple menu or something-- I think I was trying to bypass that white startupscreen or something..). However, after doing this a few times to play with it, I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.
I did have it re-partitioned to run linux as a dual boot from the SD slot or something-- I remember using that cgpt thing to select the different boot modes and vaguely recall the way it would A/B the updates (which "O" is now doing)... but anyhoo I was using the armhf ubuntu releases with the native kernel and ran into all kinds of sound issues and framebuffer only was a little crappy so...
I'm gonna re-read in more detail soon and I'm sure I'll have questions-- one of which will be-- assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?
ol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61.
Click to expand...
Click to collapse
This is the -env file I'm missing, I presume?
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
Click to expand...
Click to collapse
It looks from the response that the gapps portion might be what's in question-- just like ChromiumOS vs Chrome has all the proprietary bits taken out?
Here's what I'd ideally like to see:
* Rooted Android, with a toggle switch to hide su in settings a la lineage (requires a kernel patch something like this one) + settings changes from lineageos
* adb access from outside the device-- critical for quickly testing apks from android studio w/o a cable. Basically put the chromebook in a "device mode" where adb is passed through... I'm going to see if I can pipe adb through with socat as you suggest...
* what else... I dunno watch this space.
An update from a couple of guys that have tested out the scripts on Intel: It seems to be that while they are able to launch daemonsu manually (with daemonsu --auto-daemon), it apparently does not seem to be getting launched at boot.
I am waiting for some more information on this. Previously, for Marshmallow, the script was setting up the app_process hijack method in order to to launch daemonsu at boot; to support Nougat I changed it to instead create an .rc file with a service for daemonsu, and add a line to init.rc importing it. This works for me, and from what I can gather, it copied/created all files successfully on the testers devices, too, so I'm not sure at this point what the issue is there.
Edit: Fixed the issue. I updated my previous post with further details.
fattire said:
I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.
Click to expand...
Click to collapse
lol yeah. True, that.
fattire said:
...assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?
Click to expand...
Click to collapse
It's literally just two things that differ: the few lines where we copy the su binary over e.g.
/x86/su.pie → /system/xbin/su, daemonsu, sugote
vs
/armv7/su → /system/xbin/su, daemonsu, sugote
...and also the size of the created container. The x86 container is about 30 percent larger than the Arm one.
I had a little look at how to determine the CPU architecture programmatically on Chrome OS a while back, but couldn't seem to find a reliable way of doing this, at least not without maybe getting a bunch of people with different CrOS devices to run something like, as you mentioned, uname -i (which returns 'Rockchip' on my device, uname -m (which returns 'armv7'), or such similar, and collating the results. It was just easier to do separate versions for x86/arm, rather than introduce more conditionals (with potential for errors). I'm certainly not averse to adding a check for $ARCH, and thus standardizing the script, as long as it's reliable.
fattire said:
This is the -env file I'm missing, I presume?
Click to expand...
Click to collapse
Yep! It's just the same few envs as in the .confs, moved into a new file. I'm fairly confident that the script's conditionals deals with them OK.
fattire said:
It looks from the response that the gapps portion might be what's in question-- just like ChromiumOS vs Chrome has all the proprietary bits taken out?
Click to expand...
Click to collapse
Yeah, although the respondant there perhaps doesn't seem to realise that he's talking to a Google/Chromium dev, the way he responds. Not that that makes anything he says in his post is necessarily less valid, though.
fattire said:
Here's what I'd ideally like to see:
* Rooted Android, with a toggle switch to hide su in settings a la lineage (requires a kernel patch something like this one) + settings changes from lineageos
* adb access from outside the device-- critical for quickly testing apks from android studio w/o a cable. Basically put the chromebook in a "device mode" where adb is passed through... I'm going to see if I can pipe adb through with socat as you suggest...
Click to expand...
Click to collapse
Interesting... I agree, those would both be useful additions to the functionality of ARC++...
Quick question-- has Samsung provided the source for the GPL components (including the kernel, obviously)? I looked here but didn't see anything...? Previously the kernel was included along with the chromium source and there was like a kernel and kernel-next repository.. but this was like five years ago. I think the codename for the samsung chromebook pro is called caroline... let me quickly see if I can find a defconfig in the chromium source...
Back.. nothing here in the chromeos-4.4 branch. Nothing here either in the master branch. Maybe I'm looking in the wrong branches-- master is probably mainline kernel. Also the directories.. it took me five minutes to realize it wasn't going to be in arch/arm - force of habit I guess. I'll keep looking unless anyone knows. This "chromium-container-vm-x86" one seems to have dm_verity as an unused option. Ah, this is looking promising.
...and... here!
So it would seem that this would be built as part of the chromiumos build system, which seemed to be half gentoo five years ago building out of a chroot and was kind of a pain to set up... still, I'm guessing that since it's got that weird script to make the defconfig, what you could do is use google's chromiumos build script to make the kernel image (with whatever changes you want), then, assuming that it doesn't care if you replace the kernel, just throw it over the right Kernel A/B partition and see if it boots and starts up chromeos... it's weird cuz the kernel has to do double-duty for chromeos and android.. but I bet you can just replace it and it would work fine...
I had a cursory go at building a couple of kernel modules for my Flip C100 a while back - I didn't get too far though, lol. People do seem to have had success building their own kernels and running them with Chrome OS though, as with most things I suppose it's just how much time/effort you're willing to put in.
I think I used this and maybe this, from the crouton project to guide me.
From what I remember, I just got fed up of all the arcane errors/config choices. I remember that even though I'd imported my current device config from modprobe configs, there were then such an incredibly long string of hoops/config choices to have to go through one by one, to then be confronted with various errors (different every time ISTR) that I think I just thought "screw this". I think there were some other issue with the Ubuntu version I was using at the time as well. I know that sort of stuff's kind of par for the course with kernel compilation, but I was mainly only doing it so I could edit xpad in order to get my joypad working, in the end I found a different solution.
It shouldn't be too much hassle though, in theory I guess.... Oh, also, in order to get a freshly built kernel booting up with the CrOS rootfs, in addition to the gpt flags, I think you might have to sign it, too? (just with the devkeys & vbutil_kernel tool provided on the rootfs), some info here, and here.
From what I remember, the build system would do whatever key signing was necessary.... although I do now remember you're right there was some manual step when I was building the kernel, but I can't remember if that's because of MY changes or that was just part of the build process.
I I just dug out the old VM (Xubuntu) I was using to build and, well, let's just say I'll be doing a LOT of ubuntu updates before I can even realistically look at this. I do kinda recall setting up the environment was a huge pain so I'm going to see if I can just update the 5 year old source, target the pro and just build the kernel image and see what pops out the other end. At least I won't have to deal with the cross compiler, though I think it should hopefully take care of that itself.
Interesting to see that those crouton projects have emerged (no pun intended) so I'll check them out too while ubuntu updates itself
Thanks for the github links.. I'm going to go read that wiki.
Update: Looked at it-- funny they just stripped out the chromeos-specific parts they needed rather than emerge everything which is smart. My only question is now that Android is involved, there's that script I linked to earlier that seems to say "if you want Android support you'll need these bits too"-- wonder if the same config scripts apply, and if there are any other device tree considerations as well...
I may play a bit and see how smoothly it goes.. Unfortunately I don't have unlimited time either :/
Also, please do let me know if you put the scripts on github and I can send you pull requests if I come up with anything.
Update: Finally updated like 3 major versions of ubuntu... the "depot_tools" repo had its last commit in 2013, so I updated that. Wow, this is so much clearer than previous docs... it looks like something called gclient is used now, which I configured with:
gclient config --spec 'solutions = [
{
"url": "https://chromium.googlesource.com/chromium/src.git",
"managed": False,
"name": "src",
"deps_file": ".DEPS.git",
"custom_deps": {},
},
]
'
that let me do gclient sync --nohooks --no-history ...which i think is updating the ancient source. I probably should have just started over, but anyway... we'll see what happens.
Update again: After updating with this new gclinet tool, it appears that the old repo sync method is still required as described here. That hasn't changed after all, so now I'm going to go through this old method, which will probably completely overwhelm my storage as it's downloading with history.. but anyway, in case anyone is trying this-- looks like the whole chroot/repo sync thing may still be how it's done... the /src directory described above may only be for building just the browser, not the whole OS...
...and here it is. I will have zero room to actually build anything tho, but hey.
* [new branch] release-R58-9334.B-caroline-chromeos-3.18 -> cros/release-R58-9334.B-caroline-chromeos-3.18
Note to self: use cros_sdk --enter to actually get in the chroot. Then:
~/trunk/src/scripts $ ./setup_board --board=caroline
to set up the build for caroline. Then to build:
./build_packages --board=caroline --nowithdebug
Useful links:
* Building ChromiumOS
* [URL="http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq"]eBuild FAQ
[/URL]
This is a guide to install Debian Linux on your Nexus Player
NOTE: This guide is for advanced users
This is NOT VNC nor chroot nor Android X server nor anything else like that, but running Linux natively.
D I S C L A I M E R
----------------------------------------------------------------------------
Use this at your OWN RISK. Experimental software may harm you, your device and others around you. I cannot be held responsible for any damage done. You have been warned!
Installing Linux will most likely VOID YOUR WARRANTY! (If warranty still applies to a five year old device...)
P R O L O G U E
----------------------------------------------------------------------------
I have adapted the Nexus Player's kernel to meet GNU/Linux, namely Debian 10, requirements so far that it has become quite stable by now.
Since the processor is Intel x86 compliant you can run a regular distribution, receive updates, load software, etc. etc. This makes the Dell Venue virtually a desktop PC.
You can install Debian onto a USB stick and dual boot along with Android OR you may install Debian to the device's internal storage (and speed up things significantly).
H A R D W A R E S U P P O R T
----------------------------------------------------------------------------
What is NOT working:
* Suspend/standby
* Full 3D support
* Cameras
* Microphones (needs proper asound.conf)
* Likely something else
* Dell Venue 7840 users please see notes attached about sound. Be careful not to damage your speakers with high volumes.
R E Q U I R E M E N T S
----------------------------------------------------------------------------
* Dell Venue 7840 or Dell Venue 7040 (obviously) w/ unlocked bootloader
* USB OTG cable and mirco USB cable
* A USB Hub
* An empty USB stick (I suggest at least 16 GB of storage and 40 MB/s read and 20 MB/s write speed. 8 GB is the minimum requirement though.)
* Input devices (i.e. mouse, keyboard)
* Linux PC (or virtual machine)
* Basic Linux/ROM tinkering knowledge, some time and patience...
A lot of stuff has not been tested entirely, I am a little short of spare time lately, so please be patient, I am willing to help as good as I can.
Ready?! Let's go!
S T E P 1: Install the Linux boot image
----------------------------------------------------------------------------
a) Unlock your tablet's bootloader (there are guides online in case you don't know how to do that)
b) Reboot to bootloader, attach the tablet to your PC and flash the device specific Linux boot image to the boot partition.
fastboot flash boot dell_venue_7x40_linux_boot.img
Hint: This will be the only change to your tablet.
Note: You may revert the changes by flashing the stock boot image.
S T E P 2: Prepare SD card (done on the Linux PC)
----------------------------------------------------------------------------
a) Format the partition on the USB stick with the ext4 file system.
b) Manually mount the partition to e.g. /mnt
c) Download the attached root file system creator, untar it and change to that directory. (sorry had to be a tar inside a zip, XDA forum requirements)
d) Create the rootfs (need to be root):
./bbep_rootfs_creator /mnt your_username your_password
Note: The process sometimes fail, you might have to try more than once.
Note: This will take a long time. To speed things up, you may create the rootfs inside a disk image on your local hard drive and afterwards write the image to the SD card.
e) Download the system image (link: https://mega.nz/file/tK4UiDaB#yfmTgf8qg8e-WKFPfISbKabNeA2vd5cSfTiKCs5Oh2I)
f) Rename the downloaded system image file to system.img and paste it into /mnt
g) Insert the SD card into your tablet.
h) That's it, if you now boot your tablet, it will actually boot into Linux. Please see the debug output messages for hints in case you run into troubles.
Note: The kernel has become quite old. In case the file system gets corruptes, the kernel cannot recover the file system because the current EXT4 version is not entirely supported by the kernel. In that case, please remove the SD card and use another PC with a recent kernel to recover the file system by typing e2fsck -fy
P O S T I N S T A L L A T I O N A N D I S S U E S
----------------------------------------------------------------------------
a) sbin tools
I compiled some tools useful for running Linux on the tablet. Have a look at /usr/local/sbin. Those should be quite self-explainatory.
"toggle_blue_light" is a nifty little feature allowing you to turn on and off the blue pixel (makes the screen a little more easy on the eyes, also eliminates blue light hazard)
b) Keyboard and Dell Venue 7040
Dell has not released the kernel driver for the keyboard, so currently you won't be able to pair the keyboard using Linux. If you happen to own 2 units, you may boot Android on one of the machines and Linux on the other. Trigger the pairing in Android but then connect with the Linux machine. Swap keyboards afterwards. It's a mess...
c) Touchscreen orientation on Dell Venue 7840
Touchscreen orientation on the Dell Venue 7840 might be incorrect. In this case you need to trigger the script /usr/local/sbin/ts_rotate
d) Sound on Dell Venue 7840
Sound on the Dell Venue 7840 needs to be set up manually (you can automate the process with a start up script). You need to call /usr/local/sbin/bb_on_tfa9890.sh as root.
To change the volume use /usr/local/sbin/bb_set_volume.
Be careful with the volume, do not overdrive the speakers. I permanently damaged my 7840's speakers!
e) Compositing
On the tablet, Mate's window manager "Marco" is NOT hw accelerated. Compositing is slow. When watching Videos or browsing the internet, you may want to disable compositing (use mate-tweak) to increase performance.
If you need hw accelerated compositing you may use kwin-x11 but this takes up 1GB of disk space and stability is subpar...
You may reduce the resolution to full HD (still very good picture) by uncommenting the appropriate line in /usr/share/X11/xorg.conf.d/10-hwc.conf
f) Chromium
Chromium can be accelerated with X11/EGL, but buffer management does not work properly. When resizing the window you may need to restart Chromium, because the buffer allocation may fail.
Chromium does have support for WebGL. It's quite buggy.
g) Firefox
Firefox is not hw accelerated but still gives you decent performance when browsing or watching movies (tested Youtube FullHD and Netflix, works fine).
However when using WebGL, Chromium is much faster (in case it does not crash).
h) VLC media player
Video playback hw acceleration is not supported. To achieve decent performance anyways do as follows:
I) Choose Tools --> Preferences --> Video
II) As "Output" choose "X11 video output (XCB)" and for "Fullscreen Video Device" select "hwcomposer" for best performance.
i) Splashscreen
You can create your own splash screen. Just grap the appropriate raw flash file for your device (see below) and append a valid 24 bit image to the file (using your favorite hex editor). Flash afterwards:
fastboot flash splashscreen your_image.img
Q & A
----------------------------------------------------------------------------
Q: Does graphics acceleration work?
A: Well, OpenGL ES does work, however a lot of programs do depend on desktop OpenGL which is NOT supported. Graphics acceleration is achieved through libhybris which makes it possible to use Android graphics drivers in GNU/Linux. It might be very buggy. YMMV
Q: What is graphics performance like?
A: Depends. When a program supports OpenGL ES, you get decent performance (e.g. Kwin-X11 window manager, Chromium). Performance is sufficient to watch FullHD movies in Firefox or with VLC or browse the internet. Chromium supports accelerated WebGL.
Q: What is system performance like?
A: Depends. Bottle neck of system performance is the speed of the storage used. Using the internal storage gives huge speed improvements vs. an external USB storage (max ~ 30 MB/s). With internal storage simple tasks like file management, office applications etc. work fine.
S O U R C E C O D E
----------------------------------------------------------------------------
* Halium - https://github.com/halium
* Libhybris - https://github.com/NotKit/ and https://github.com/libhybris/
* Debian - https://www.debian.org/
* Kernel - https://android.googlesource.com/kernel/x86_64/+/refs/heads/android-x86_64-fugu-3.10-nougat-hwbinder , https://github.com/fcipaq/android_kernel_asus_fugu
* Lineage OS - https://github.com/lineageos
C R E D I T S
----------------------------------------------------------------------------
Special thanks goes to the Halium team, especially JBB and NotKit
And to Hybris, Debian and the LOS team
ROM OS Version: Debian 10
ROM Kernel: Linux 3.10.20
ROM Firmware Required: 5.x
Graphics drivers based On: Lineage OS 14.1
Version Information
Status: 7040 ok, 7840 untested
Created 2021-01-30
Last Updated 2021-02-25
Watch the demo on youtube:
20 days now, believe it or not but I have been waiting for something like that...sort of. Well, I'm gonna give it a try and see if I can provide you with some feedback.
Thanks, amazing idea.
Glad to finally get any feedback
Which device are you using? I have made some progress with the 7040 version - the attachable keyboard now works! I'll update the image file later.
Good luck with the installation and don't hesitate to contact me if you run in any difficulties...
I'm running the 7840. You wouldn't manage to get some kind of an installation script would you?
Well... I'm afraid a script is not possible as it includes to many different platforms...
However I can upload an image of the SD card (I'm currently already working on that) so that you would basically just have to put it onto a SD card.
Linux is running quite well now on the 7840. Even Bluetooth is working without any need of configuration...
So please be patient, may take some days...
fcipaq said:
Well... I'm afraid a script is not possible as it includes to many different platforms...
However I can upload an image of the SD card (I'm currently already working on that) so that you would basically just have to put it onto a SD card.
Linux is running quite well now on the 7840. Even Bluetooth is working without any need of configuration...
So please be patient, may take some days...
Click to expand...
Click to collapse
Amazing to hear that, thanks for your work. Really looking forward to that.
K, you got it! The links to the file system are online now, as well as the new kernels. Let me know how you like it!
PS: The kernel for the Dell Venue 7840 is running with reduced resolution. If you intend to only use the table in portrait mode I can post an boot image running full resolution...
Thank you, I'm currently very busy with exams, I'll look into it the end of this week. Thank you very much for your efforts.
Fingers crossed for your exams!
Also, I've now implemented the ability to set a custom wifi mac and country code using the kernel command line. This can be set by editing the image file with a hex editor (command line is right at the beginning of the file, there is no checksum which has to be recalculated).
Alright, working good so far. Battery drain is pretty high, I assume thats due to the lacking suspension mode. Oh and sound would ofc be nice x). Graphics acceleration would be nice to have and I guess improve battery run time.
Congrats you got it working (first confirmed!)
I find battery performance quite decent when actually running (i.e. using) the system. I get approx 8 hours of uptime, but I agree that standby performance is indeed terrible - as you already stated this is due to the lack of suspend mode. You actually need to shutdown the tablet when not in use.
Graphics acceleration is (I'm quite sure) not going to happen. Linux is lacking a PowerVR open source drivers, many have tried but no success so far afaik.
Sound drivers appear to be tricky. I found at least two pieces of code to be problematic in a 32 bit kernel, but might be working in a 64 bit kernel. However, Intel/Dell seem to do some initializing in user space code which is unavailable. So doesn't look to good for sound...
I installed Linux the the device's internal EMMC (purged Android) which is really boosting performance (internal storage is approx three times the speed compared to the external SD card reader's max speed...)
I tweaked the kernel a litte, it is now possible to choose between full and reduced resolution/color at kernel command line as well as a custom wifi MAC address and country code. I'll upload the updated kernel once I'll return from vacation...
PS: Hope your exams went well!
Awesome! I've been trying to figure out something interesting to do with my 7840. I'll likely have to wait until this weekend to flash it but am looking forward to doing so. Thank you for your work on this.
This is awesome!
I have been waiting for someone to do something exciting with this little guy. Thank you, seriously. I will be flashing this on mine and following along with your progress. This remains my favorite tablet to date (and I have gone through plenty), such a shame dell shut it down and it didn't get too much love from the community.
Well I had some issues with the state of my tablet after the last time I played with it; so things took a little longer to get going than I expected. But I was successful at getting this loaded and so far so good! I am not really seeing any slowness (using a Class 10 U3 mircoSD) but would be interested in the process to purge the Android file system as it would be more convenient at start-up.
I was able to connect to my WiFi using both wireless N and AC standards. In the little bit of testing I have done so far, sound and touch are working quite well. I did notice that the screen rotation script didn't redraw the desktop, but the touch locations seemed to change orientation. I have not yet tried to figure out why.
@fcipaq You have probably already seen libhybris but if not it may be worth looking at for 3D acceleration. I am not completely positive it is relevant as it may be specific to ARM processors. https://github.com/libhybris/libhybris/
It's been a while - sorry! I'm glad to get your feedback. I have been quite busy lately (and still am). I recently made only some minor tweaks/adjustments, e.g. patched to kernel against the blueborne vulnerabilty.
My 7840 is dead now as the connector failed (connected it too many times to my pc) - this is the sacrifice I made But I still have my 7040 up and running - which is basically the same device. I suggest you do a lot of the flashing from the linux command line or buy a magnetic charger cable ($5 on ebay) to reduce wear on the connector - it's quite delicate and really hard to repair (if you find any spare parts at all).
The rotation script is for touch only - this will not alter the screen rotation. The screen rotation (unfortunately) can only be changed by rebooting (or logging our and in again/restarting the X server).
@FairOh: Thank you for the hint. I am aware of that option but it would take quite some engineering effort and that is far beyond what I can do (alone). The current driver does not even give you 2D-acceleration...
I will upload an updated kernel asap as well as I will publish the kernel source so that others may contribute or study...
I benchmarked the internal EMMC and the SD-Card read/write speeds (I used a really fast SD card) and it turns out that the internal storage is about 3-4 times the speed of the external card. I think this is the card reader's limitation.
FYI: If anyone who reads this owns an Asus Zenfone 2 - this is almost the same hardware and a lot of code can directly be ported - I just took a quick glance at the Asus source code... (and to be honest, I took the wifi driver )
No rush, but curious if you have been able to get your source files uploaded/shared. Not that I'm much if a developer, but you gotta start somewhere.
@FairOh: I'm really sorry for my delayed response. I have been very busy lately...
BTW: it was my first project of that kind. I greatly appreciate your interest. Maybe you can figure something out.
Well source code is now online as well as the updated flashable boot images. Feel free to alter the source code in any way, republish, modify, share, learn etc...
I made some remarks inside the archive (readme file) to guide you to a running build quickly. I suggest you use the toolchain (compiler) from google (instructions provided inside the archive), otherwise the code might not compile properly.
Please let me now if you run into any difficulties compiling the code or setting up the build environment...
So far, so good
First of all, I want to thank you so much for your work on this.
I have a 7040 and I was really concerned about Blueborne vulnerability. I tried a few months ago this, but unfortunately I wasn't be able to get working the Bluetooth adapter, so the built-in keyboard/mouse weren't working (Firmware contents were in place, so I didn't really know what happened).
This time, December revision, I run into the same problem and also when I want to update the system, Ubuntu ask me the admin or root user password.
If you don't mind share the admin/root password, I would be very glad to try and fix the Bluetooth adapter in my system and maybe tweaking some system settings.
Finally, I want to thank you again. Our little loved devices can do so much things because of you. Maybe sometime in the future I will be able to dig in the source code and collaborate in these project (First, I have to learn a lot of things, but I think I will).
Glad you like it!
I might have forgotten to mention that the password is simply "password" sorry!
First of all you need to make sure that your bluetooth adapter is working at all (you may try to pair with any bluetooth device). All you basically need to do is to put the firmware files in place.
Connecting to the magnetically attachable keyboard is a whole different story. As Dell has not released the kernel source for the Dell Venue 7040 (but only for the 7840 model) I had to reverse engineer the driver for the keyboard. There are four pins (two inner pins and two outer ones) connecting the keyboard to the tablet. The outer ones are used to supply power whereas the inner ones serve to put the keyboard into pairing mode - using a "secret" protocol which I have not figured out. So here is what I did to get it working anyways:
1. Boot into Android
2. Delete the Dell keyboard from within the bluetooth menu (this will immediately cause Android to try and reconnect)
3. When prompted to enter the pin just click on cancel (the keyboard will remain in pairing mode for another minute awaiting incoming requests)
4. On another Ubuntu PC search for pairable bluetooth devices. Once the Dell keyboard has been detected connected to it.
5. On the Ubuntu PC tar/copy the key files in /var/lib/bluetooth/XX:XX:XX:XX:XX:XX
sudo tar czf btkeys.tar.gz XX:XX:XX:XX:XX:XX
(These are the keys the Ubuntu PC brokered with the keyboard - we are going to reuse these on the Android tablet)
Hint: Both PCs need to have the SAME bluetooth MAC address.
6. Reboot the tablet into Ubuntu and copy the tared file over to /var/lib/bluetooth.
7. Untar this file on the Android tablet in /var/lib/bluetooth
sudo tar xzf btkeys.tar.gz
8. Reboot (The Android tablet now has matching keys to connect to the keyboard).
BEWARE: Booting into Android will result in resetting the keyboard and you will have to do the procedure all over again. You may use electrical tape to disable the two inner pins thus preventing Android from telling the keyboard to go into paring mode)... It's a littel complex... I asked Dell twice to publish the source code but to no avail (did not even receive an answer)
Hi,
Firstly, installing desktop OS's of whatever sort on the Android version (YB1-X90F), insofar as anyone has managed it, is a completely different process and none of what follows is likely to be relevant.
Secondly, it should go without saying that any use of the linked ISO or the information in this post is entirely at your own risk.
There are several threads on xda and elsewhere dealing with attempts to install Linux on the Windows version of the Yoga Book (YB1-X91F). They're pretty consistent in terms of results, both with each other and my own attempts. I have tried the latest and previous LTS or main releases Debian, Ubuntu (all flavours), Mint and Fedora.
Between mine and others' attempts, most distros have the following working, using a Live ISO flashed to USB:
- Boot to desktop and successful install to eMMC
- Display
- Graphics pad responds to touches, but not aligned with screen rotation and probably in need of other calibration.
- USB, including ethernet-to-USB adapter
Some distros/versions additionally have:
- Touchscreen (only newer kernels, I think 4.13 onwards but definitely 4.15 onwards)
- Sound via HDMI
- Not sure about Bluetooth - possibly
The following didn't work with any distos/versions:
- A lot of the ACPI subsystem, meaning that some ICs (e.g. SD Card) don't receive power.
- Wifi
- SD Card
- Sound via headphones or speakers
- Halo Keyboard
- Touchscreen multitouch
- Battery gauge
- OS control of battery charger IC, though the IC sits in autonomous mode so the device still charges
- Display brightness adjustment (always set to max)
- Display auto-rotate
The Mint ISO linked at the end of this post has WiFi, the SD Card, two-finger right click and brightness adjustment working in addition to the OOTB functionality. I've made a lot of progress on the sound - the driver and codec load but it needs some configuration. I have read elsewhere that configuring this incorrectly can blow your speakers which is why I haven't tackled it yet.
The Halo keyboard doesn't work yet, so the Yoga Book can't be used in laptop mode for now. The only real barrier to using it in tablet mode is the lack of a functioning battery gauge. More on this below.
Instructions:
You will need a USB flash drive of at least 2GB, a USB keyboard and mouse and therefore a USB hub as well as a way of attaching it to the micro-usb port. I use an OTG adapter which came with a Samsung phone.
The touchscreen does not work when the Live ISO boots but it does work after installation.
Once Linux is installed on the eMMC, the firmware will boot to GRUB by default rather than Windows. To boot into Windows you have to enter the firmware menu. This should be easy to fix/reconfigure but I haven't got round to it yet. I need to get the volume and power keys working in GRUB first.
- Download the ISO from the link below and flash to USB. I use Etcher on MacOS which flashes in a dd-like manner (other tools make their own changes to the target drive to make it bootable - this isn't needed or desirable).
- Turn off hibernate, fast boot and secure boot in Windows. There are easily found guides on how to do this. It ought to be possible to retain secure boot but I have found doing so a real headache on other systems so didn't try in this case.
- Turn off any secure boot settings in the device firmware (access the menu by powering on with the volume up button pressed down).
- Using the firmware menu, boot from the flashed USB drive. When the desktop boots, use GParted to shrink the Windows partition, leaving at least 11GB (Mint says it needs 10.7GB). I've been messing around with Linux for months now on the YB and have found 11 enough.
- Run the desktop installer. At the partitioning menu, choose 'Something else'.
- Create a new Ext4 partition using all of the free space created previously and map it to '/'.
- Ignore any warnings about a swap partition. If you get stuck on a dialog about forcing a UEFI install, open a terminal and run 'killall ubiquity' then run the installer again with the network connection turned off. If the install doesn't work, you may have to risk the default 'Install Mint alongside Windows....' option. I have never had a problem with this, but I don't quite trust it, or indeed the installer in general.
- If you fail at the point of GRUB install, go back and start again with networking disabled.
- Just reboot as normal.
Changes from Stock ISO (probably not exhaustive)
- New ISO using 18.3 Cinnamon as a base using Cubic
- Updated, inc dist-upgrade as of 6 Sept 18
- Missing Broadcom firmware (for WiFi) added.
- Additions to /etc/skel/.config to put Mint into HiDPI mode
- Florence on screen keyboard added and loads on start
- Touchegg, which enables two-finger right click added and loads on start.
- LightDM settings changed to enable Florence and HiDPI
- Most importantly, a custom kernel (4.18.5) which is responsible for most of the above-OOTB functionality. Some of this is just about enabling the correct Atom ACPI ICs, other bits relate to load order (to get past the lack of brightness control).
Help!
- I really need some help with the battery gauge IC. For now, dmesg is the best bet but I'll follow up with another post with more detail.
- There are other things which need doing, e.g. the keyboard and finishing off the sound but these are relatively straightforward by comparison. The gauge/charger setup is the last low level thing not working.
Custom ISO:
This is my first post. I can't post links! Remove the spaces and ..... :
drive.google.com/ .... open? .... id=1-5vtnKAVpERmzTFIR3TGXe1DgvoFvehc
Help Needed - Battery Gauge/Charger
The issue
The following can be seen by running 'dmesg' after boot using the ISO in my first post, which uses a 4.18 kernel customised for the hardware in the Yoga Book.
The kernel attempts to load the driver for the TI bq24190 battery charger IC. I'm not yet able to post links so search for 'bq24190_charger.c' in the Linux kernel Github repo. The driver throws an error on boot when it hits this code at line 1640. It's expecting a 6 and it gets a 4, the value of BQ24190_REG_VPRS_PN_24190.
bq24190_charger.c
Code:
if (v != BQ24190_REG_VPRS_PN_24190 &&
v != BQ24190_REG_VPRS_PN_24192I) {
dev_err(bdi->dev, "Error unknown model: 0x%02x\n", v);
return -ENODEV;
}
If I remove this check altogether and re-compile the module then the driver proceeds to load but reports zeroes for all status values. It's not clear whether it is, in fact, the right chip and isn't talking to the rest of the hardware or it's simply the wrong driver.
However, at least removing this check allows the Whiskey Cove ACPI IC driver to get a bit further along. Search for 'intel_cht_int33fe.c' in the kernel source. Comments in this file (line 124) confirm that this IC is expected to be paired with a bq24190.
By adding in dmesg warnings and re-compiling the int33fe module I could see that when an unmodified bq24190 driver is used, i.e. the check above takes place and is failed, the int33fe driver fails its own check at line 138:
intel_cht_int33fe.c
Code:
regulator = regulator_get_optional(dev, "cht_wc_usb_typec_vbus");
if (IS_ERR(regulator)) {
ret = PTR_ERR(regulator);
return (ret == -ENODEV) ? -EPROBE_DEFER : ret;
}
regulator_put(regulator);
When I remove the check, it fails at the next check starting at line 145:
Code:
/* The FUSB302 uses the irq at index 1 and is the only irq user */
fusb302_irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 1);
if (fusb302_irq < 0) {
if (fusb302_irq != -EPROBE_DEFER)
dev_err(dev, "Error getting FUSB302 irq\n");
return fusb302_irq;
}
I have tried various combinations of including the FUSB driver and dependencies as modules/built in but the result is the same. I also tried moving the FUSB check to after the code which tries to link up with the max17047 battery gauge IC, but this fails also.
Some owners of the Android version of the Yoga Book have posted files/screenshots on Telegram which indicate that a different charger, the bq25892 is used. As far as I know i2c devices are simply identified by the fact that they occupy a certain address on the bus. You can see in the datasheet for the bq24190 (sorry, no links!) on page 3 that it uses i2c address 6BH. The datasheet for the bq25890/2 shows on page 5 that the bq25892 also uses 6BH.
I don't know enough about i2c to know whether this is the issue, or how to point Linux to a different driver in the way that you might using a VIDID for a USB or PCI device? It would be really helpful if anybody could definitively confirm which chip we are dealing with.
Some final ACPI errors crop up towards the end of the dmesg output (I've cleared all the others) and I suspect that sorting this will clear them, as well as making the Yoga Book with Mint usable in Tablet mode.
Other things which need fixing:
- There are sound errors in the dmesg output but it also shows that the drivers and codec are loading properly. I can see all the devices which should be visible in amixer from the command line. Because getting the config wrong can blow speakers I've resisted tackling this until I've done further research but if anyone has a solution please let me know.
- Halo Keyboard. This needs either a kernel module to be written or a software layer which runs at least under X. I don't expect this to be hugely difficult - Linux can see the Halo as a wacom graphics pad and take input, albeit not deal with it properly yet. There's also a mystery, generic HID device which by process of elimination must be the button/backlight. However, the generic HID driver loads so it shouldn't be too hard to work out how to talk to it.
- I re-built the ISO using Cubic. When I have tried to make ISOs which use my custom kernel to boot the ISO itself, they don't work. I get garbled graphics and the boot stalls. This is why the touchscreen doesn't work when you live boot (which uses 4.10) but does when you install (because it uses 4.18). This ought not to be insurmountable but I haven't cracked it yet. I've tried doing it manually and using the Debian live-boot commands for both Debian/Ubuntu. Still no luck.
- Until I can get a custom ISO to boot from a custom kernel it won't be possible to install on the SD Card. Otherwise, there's no reason this shouldn't be possible.
- It should be possible to install to another USB device now, but I haven't tried yet. Make sure to use the disable MMC script on the desktop if you don't want to install Grub EFI on the eMMC. Ubuntu and derivatives ignore whatever you choose for this and just use the fist EFI partition they find. Amazingly this bug has been there since 2014!
- It ought to be possible to map the hardware buttons (volume, power) to specific keys in Grub, possibly using a locale. This would allow selections to be made without a keyboard.
android install
This might be related as I was just installing windows on Android version and now reverted back (https://forum.xda-developers.com/showpost.php?p=77556606&postcount=44), couple of observations that might help you: On android reinstall back it required to activate halo keyboard to get it working again, there was a phone code entered into the search bar to get it activated which triggered something called easyimage app. In android stock image you can actually find easyimage.zip which I guess is this "fake android update" to install the halo keyboard. Inside the zip are *.so libraries and some files related to halo keyboard and ink pen so you could try to play with those to get it working under classic Linux.
DNX mode allows to boot EFI via a USB cable &*fastboot (I guess windows version have also this as I activated it somewhere in BIOS?) so this can be also alternative version of booting an OS. IMHO Grub can also chainload iso image directly (I did it in past on normal PC, it was a couple of years ago so I can't find the guide to do it now) so in theory you can just place the Linux ISO image as a normal iso file on disk and tell GRUB to chainload that directly. Since it's possible to revert the Windows installation back to Android it might even be possible to dualboot. Android bootloader is also EFI based (kernelflinger) so you could also play with that. TWRP recovery image have full touch support for screen so that might be also a help when digging for configuration or extracting it from the sources.
intense.feel said:
...you can actually find easyimage.zip which I guess is this "fake android update" to install the halo keyboard. Inside the zip are *.so libraries and some files related to halo keyboard and ink pen so you could try to play with those to get it working under classic Linux.
Click to expand...
Click to collapse
This is really helpful, thank you. I'll have a look at what's there.
Still no progress with the battery gauge...
intense.feel said:
This might be related as I was just installing windows on Android version and now reverted back (https://forum.xda-developers.com/showpost.php?p=77556606&postcount=44), couple of observations that might help you: On android reinstall back it required to activate halo keyboard to get it working again, there was a phone code entered into the search bar to get it activated which triggered something called easyimage app. In android stock image you can actually find easyimage.zip which I guess is this "fake android update" to install the halo keyboard. Inside the zip are *.so libraries and some files related to halo keyboard and ink pen so you could try to play with those to get it working under classic Linux.
DNX mode allows to boot EFI via a USB cable &*fastboot (I guess windows version have also this as I activated it somewhere in BIOS?) so this can be also alternative version of booting an OS. IMHO Grub can also chainload iso image directly (I did it in past on normal PC, it was a couple of years ago so I can't find the guide to do it now) so in theory you can just place the Linux ISO image as a normal iso file on disk and tell GRUB to chainload that directly. Since it's possible to revert the Windows installation back to Android it might even be possible to dualboot. Android bootloader is also EFI based (kernelflinger) so you could also play with that. TWRP recovery image have full touch support for screen so that might be also a help when digging for configuration or extracting it from the sources.
Click to expand...
Click to collapse
I'm currently doing on that without the Hardware. my plan is to find the small / light weight linux kernel and port the driver of the HALO. I call this Project HALO port (not on github cuz I just gathering everything until I ready). right now I'm learning to compile the kernel because I never do that (3 years on linux xD). I hope soon I can figure out the protocol it did uses for the HALO (My guess is I2C/SMBus).
Update : I found someone on github just build custom Debian ISO to deploy on USB flash drive and be able to use HALO keyboard (A.K.A Yeti, based on Goodix gt9xx chip). This is his work on github
Woah this is amazing progress! I haven't been on the forums for a while; been working mostly on messing with Windows to make it more efficient and responsive lol.
jimnarey said:
The issue
The following can be seen by running 'dmesg' after boot using the ISO in my first post, which uses a 4.18 kernel customised for the hardware in the Yoga Book.
The kernel attempts to load the driver for the TI bq24190 battery charger IC. I'm not yet able to post links so search for 'bq24190_charger.c' in the Linux kernel Github repo. The driver throws an error on boot when it hits this code at line 1640. It's expecting a 6 and it gets a 4, the value of BQ24190_REG_VPRS_PN_24190.
bq24190_charger.c
Code:
if (v != BQ24190_REG_VPRS_PN_24190 &&
v != BQ24190_REG_VPRS_PN_24192I) {
dev_err(bdi->dev, "Error unknown model: 0x%02x\n", v);
return -ENODEV;
}
If I remove this check altogether and re-compile the module then the driver proceeds to load but reports zeroes for all status values. It's not clear whether it is, in fact, the right chip and isn't talking to the rest of the hardware or it's simply the wrong driver.
However, at least removing this check allows the Whiskey Cove ACPI IC driver to get a bit further along. Search for 'intel_cht_int33fe.c' in the kernel source. Comments in this file (line 124) confirm that this IC is expected to be paired with a bq24190.
By adding in dmesg warnings and re-compiling the int33fe module I could see that when an unmodified bq24190 driver is used, i.e. the check above takes place and is failed, the int33fe driver fails its own check at line 138:
intel_cht_int33fe.c
Code:
regulator = regulator_get_optional(dev, "cht_wc_usb_typec_vbus");
if (IS_ERR(regulator)) {
ret = PTR_ERR(regulator);
return (ret == -ENODEV) ? -EPROBE_DEFER : ret;
}
regulator_put(regulator);
When I remove the check, it fails at the next check starting at line 145:
Code:
/* The FUSB302 uses the irq at index 1 and is the only irq user */
fusb302_irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 1);
if (fusb302_irq < 0) {
if (fusb302_irq != -EPROBE_DEFER)
dev_err(dev, "Error getting FUSB302 irq\n");
return fusb302_irq;
}
I have tried various combinations of including the FUSB driver and dependencies as modules/built in but the result is the same. I also tried moving the FUSB check to after the code which tries to link up with the max17047 battery gauge IC, but this fails also.
Some owners of the Android version of the Yoga Book have posted files/screenshots on Telegram which indicate that a different charger, the bq25892 is used. As far as I know i2c devices are simply identified by the fact that they occupy a certain address on the bus. You can see in the datasheet for the bq24190 (sorry, no links!) on page 3 that it uses i2c address 6BH. The datasheet for the bq25890/2 shows on page 5 that the bq25892 also uses 6BH.
I don't know enough about i2c to know whether this is the issue, or how to point Linux to a different driver in the way that you might using a VIDID for a USB or PCI device? It would be really helpful if anybody could definitively confirm which chip we are dealing with.
Some final ACPI errors crop up towards the end of the dmesg output (I've cleared all the others) and I suspect that sorting this will clear them, as well as making the Yoga Book with Mint usable in Tablet mode.
Other things which need fixing:
- There are sound errors in the dmesg output but it also shows that the drivers and codec are loading properly. I can see all the devices which should be visible in amixer from the command line. Because getting the config wrong can blow speakers I've resisted tackling this until I've done further research but if anyone has a solution please let me know.
- Halo Keyboard. This needs either a kernel module to be written or a software layer which runs at least under X. I don't expect this to be hugely difficult - Linux can see the Halo as a wacom graphics pad and take input, albeit not deal with it properly yet. There's also a mystery, generic HID device which by process of elimination must be the button/backlight. However, the generic HID driver loads so it shouldn't be too hard to work out how to talk to it.
- I re-built the ISO using Cubic. When I have tried to make ISOs which use my custom kernel to boot the ISO itself, they don't work. I get garbled graphics and the boot stalls. This is why the touchscreen doesn't work when you live boot (which uses 4.10) but does when you install (because it uses 4.18). This ought not to be insurmountable but I haven't cracked it yet. I've tried doing it manually and using the Debian live-boot commands for both Debian/Ubuntu. Still no luck.
- Until I can get a custom ISO to boot from a custom kernel it won't be possible to install on the SD Card. Otherwise, there's no reason this shouldn't be possible.
- It should be possible to install to another USB device now, but I haven't tried yet. Make sure to use the disable MMC script on the desktop if you don't want to install Grub EFI on the eMMC. Ubuntu and derivatives ignore whatever you choose for this and just use the fist EFI partition they find. Amazingly this bug has been there since 2014!
- It ought to be possible to map the hardware buttons (volume, power) to specific keys in Grub, possibly using a locale. This would allow selections to be made without a keyboard.
Click to expand...
Click to collapse
Not sure if you've seen, but this issue on the above GitHub project that has managed to get the battery gauge working says they're using the BQ27542.
https://github.com/jekhor/yogabook-linux-kernel/commit/f0b7662fa10f012410170c241a9fa91295f54dc1
Hi, I am the author of the repository mentioned above, https://github.com/jekhor/yogabook-linux. My linux porting efforts were focused at kernel, getting battery charger driver and halo keyboard working basically. So, this kernel supports the battery gauge, battery charger (with fast charging mode, yes!). For halo keyboard patch for the goodix touchscreen (touchpad really) kernel was needed, see the https://github.com/jekhor/yogabook-linux-kernel/commit/bd3a5953126fd87e4218550c5a31baafcdc60a38 commit. There is userspace keyboard driver in the Chromium OS which converts touchpad events into keypresses. Forked version suitable for build at GNU\Linux system is here: https://github.com/jekhor/chromiumos_touch_keyboard .
Some patches were accepted to the mainline Linux already:
0e116237aa42 extcon-intel-cht-wc: Make charger detection co-existing with OTG host mode (v5.1)
ff6cdfd71495 ACPI / x86: Make PWM2 device always present at Lenovo Yoga Book (v5.1)
236c765d6abc mfd: intel_soc_pmic_chtwc: Register LED child device (v5.2)
a72a1be0de71 extcon: intel-cht-wc: Enable external charger (v5.2)
Feel free to ask me about this work and to create github issues. This is my spare time project, so I will glad to see other developers connected.
nice project dude was trying it today and touchscreen works good so far,
but i cant get the halo keyboard to work, if i try to use it my mouse only moving from left to right and right to left.
if i can help you with creating some logs or something else, just write me i'm not rly good on linux, but i want to use it on this low power device
edit: and yes i tried to reload the kernel modules (if modprobe is the correct command) but no change
i dont know if the problem is maybe that i have a germany keyboard layout, changing in the menu works for my hw keyboard but on the halo no difference still only mouse movement
blgblade said:
nice project dude was trying it today and touchscreen works good so far,
but i cant get the halo keyboard to work, if i try to use it my mouse only moving from left to right and right to left.
if i can help you with creating some logs or something else, just write me i'm not rly good on linux, but i want to use it on this low power device
edit: and yes i tried to reload the kernel modules (if modprobe is the correct command) but no change
i dont know if the problem is maybe that i have a germany keyboard layout, changing in the menu works for my hw keyboard but on the halo no difference still only mouse movement
Click to expand...
Click to collapse
Hmmm... You are second people who reports such problem with this image. What YB version you have? I have YB1-X91L only.
Could you please post an output of the command 'sudo cat /sys/class/dmi/id/*' (use external keyboard for this)?
---------- Post added at 10:36 PM ---------- Previous post was at 10:30 PM ----------
Arghhh... I have lost one part of goodix touchscreen driver patch and keyboard will works only at YB1-X91L model (not X91F). Wil be fixed.
jekhor said:
Hmmm... You are second people who reports such problem with this image. What YB version you have? I have YB1-X91L only.
Could you please post an output of the command 'sudo cat /sys/class/dmi/id/*' (use external keyboard for this)?
---------- Post added at 10:36 PM ---------- Previous post was at 10:30 PM ----------
Arghhh... I have lost one part of goodix touchscreen driver patch and keyboard will works only at YB1-X91L model (not X91F). Wil be fixed.
Click to expand...
Click to collapse
yep i have a YB1-X91F
ok nice, than i will wait for the next release
i found out 2 things that did not work (or not correctly or i'm to stupid xD)
- sound (but i allready see the post in issues )
- the gui and if i tried video it looks like there is no graphic driver installed (dont know how to specify this, but if i just move a window it looks like software rendering, ok my english should be better to explain this but i hope you know what i mean ^^)
if i found something more i will give you feedback
but for now, its rly nice work
thank you so much for this project
here the output from the command above
Code:
08/26/2016
LENOVO
04WT18WW
NO Asset Tag
INVALID
HA0QPQ1T
LENOVO
Not Defined
NO Asset Tag
HA0QPQ1T
11
LENOVO
X91F
dmi:bvnLENOVO:bvr04WT18WW:bd08/26/2016:svnLENOVO:pnLenovoYB1-X91F:pvrX91F:rvnLENOVO:rnINVALID:rvrNotDefined:cvnLENOVO:ct11:cvrX91F:
cat: /sys/class/dmi/id/power: Is a directory
(TBD)
Lenovo YB1-X91F
HA0QPQ1T
LENOVO_BI_04_PCG_FM_YB1_X91F
41564e49-494c-0044-0000-000000000000
X91F
cat: /sys/class/dmi/id/subsystem: Is a directory
LENOVO
MODALIAS=dmi:bvnLENOVO:bvr04WT18WW:bd08/26/2016:svnLENOVO:pnLenovoYB1-X91F:pvrX91F:rvnLENOVO:rnINVALID:rvrNotDefined:cvnLENOVO:ct11:cvrX91F:
blgblade said:
yep i have a YB1-X91F
ok nice, than i will wait for the next release
i found out 2 things that did not work (or not correctly or i'm to stupid xD)
- sound (but i allready see the post in issues )
- the gui and if i tried video it looks like there is no graphic driver installed (dont know how to specify this, but if i just move a window it looks like software rendering, ok my english should be better to explain this but i hope you know what i mean ^^)
if i found something more i will give you feedback
but for now, its rly nice work
thank you so much for this project
[/CODE]
Click to expand...
Click to collapse
I have uploaded fixed iso (halo keyboard should work): https://github.com/jekhor/yogabook-linux/releases/tag/livecd-test3.1
Yes, no sound, no force-feedback for keypresses.
Don't know about video driver and acceleration, need to check.
jekhor said:
I have uploaded fixed iso (halo keyboard should work): https://github.com/jekhor/yogabook-linux/releases/tag/livecd-test3.1
....
Click to expand...
Click to collapse
yes, the keyboard is now working, nice thank you
i will follow your progress and try to help if i can ^^
hey all, because @jekhor is using a diffrent keyboard layout (not only mapping are diffrent) i created a modified layout.csv
(on this page --> https://forums.lenovo.com/t5/Yoga-Book-Windows/Yoga-book-Window-keyboard-layout-wrong/td-p/3705108 <-- you will see the layout diffrences)
layout.csv as attachmant (as txt because csv is not allowed ^^)
changes:
- Enter key diffrent size
- # moved to the other position
- added the > < | key (dont know the name )
- LeftShift key diffrent size
edit: i created a patch for the filesystem.squashfs file, just unpack the patcher in the /live/ folder on your stick and run it or run it ffrom any location you want and choose the live folder from the app, than you can use the keyboardlayout on the livesystem (sorry, the patcher is windows only)
Thanks for all the hard work
Hey all, just came across this thread recently - really appreciate all the hard work here. I've been trying to install Ubuntu on my Windows powered YogaBook since the beginning, and am amazed at how far your efforts have come. Looking forward to the completed product later on! Can't stand Win10 as it tends to bloat and slowdown. Hopefully Linux runs better on this thing.
Thxxx man
Love the level of involvement in this adforable and light device with great potential in linux
Hope u guys dont lose patience in the development.
Once the wifi, keyboard and touch screen is aredy, i think i will fully change my android yogabook into linux.......
---------- Post added at 02:01 PM ---------- Previous post was at 01:56 PM ----------
Love the level of involvement in this adforable and light device with great potential in linux
Hope u guys dont lose patience in the development.
Once the wifi, keyboard and touch screen is aredy, i think i will fully change my android yogabook into linux.......
Thanks for the effort
Thanks again, all for the effort.
Has there been any progress made so far?
It has been more than 2 full years, one in this forum has been able to achieve in only a few weeks of coding what MOST of us have tried to achieve in years. He has uploaded his ISO of Debian with many things working, however some things are left to be desired : Resume keyboard (tried with script - failed), fix for keyboard keys layout, and the resolution (worked with XRANDR script : working). However, he does not seem either interested in going further or does not have the device to compile against, either way without him we could be stuck with WinBlows on this machine. Until we get him BACK on board, we are stuck in the water... @jekhor ?
Jeff said:
It has been more than 2 full years, one in this forum has been able to achieve in only a few weeks of coding what MOST of us have tried to achieve in years. He has uploaded his ISO of Debian with many things working, however some things are left to be desired : Resume keyboard (tried with script - failed), fix for keyboard keys layout, and the resolution (worked with XRANDR script : working). However, he does not seem either interested in going further or does not have the device to compile against, either way without him we could be stuck with WinBlows on this machine. Until we get him BACK on board, we are stuck in the water... @jekhor ?
Click to expand...
Click to collapse
RN, I use the systemd to fix keyboard resume and very soon I will working on sound driver totally ported from android kernel. Plus I can get the haptic feedback to (partially) works only random left or right motor via using udev rule. Extra, the recent kernel added support for the front facing camera (ov2740).