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.
Hello,
THBK1-10 is a cheap dual system (Android 4.2.2 /Windows 8.1) tablet based on Bay Trail (Intel Atom Z3740D). More details http://www.thomsoncomputing.eu/dualboot.html
I'm trying to hack it, and especially get root and use non-signed zip in recovery. Basically i'm stuck at theses points, and i'm requesting directions to continue the work.
I have posted in W8 section, but obviously, this is no longer the place
General
------------
* i can use a work-around to write system (/system, /data) partitions
* i can flash signed updates via recovery
* google apps are working flawesly. Only thing is to keep original files (stock keyboard and layout)
-> i would like to flash non-signed zip via recovery, but i guess i have to build a custom recovery, or can i exploit something else ?
Root:
-------
* no auto root is working (z4root, towelRoot). Regarding towelRoot, i tryed each 8 common parameters, and i don't really know how to do others. I have also heard this is only working in 4.4.2+
* pushing su is not working. When i'm launching it, let's say from terminal, i have a code 255 return (-1). Tested with both arm and x86 version (i'm still wondering why arm su is also returning -1, i would have expect a non valid binary. Or perhaps my x86 version is bad ?
-> i'm still trying to dig this issue, and idea on how i could do ? i believe running SU was enough... but it seems not. Any idea ?
Many thanks !
Bump. the way it is booting is based on ramdisk images (one for normal android boot, one for android recovery).
I have acces to theses img, and i can, with hexedit (perhaps mounting them directly at a filesystem), view the whole init sequence.
My question is : what triggers the root invalidation ? AFAIK, everything is done as root (mounting FS, updating permissions, etc....). Basically i can't really figure how it is handled.
Thank you !
Solved !
Graveen said:
Solved !
Click to expand...
Click to collapse
Woaw ! I'm very happy to see that somebody tried and succeed to root the THBK1 ! Please can you share your method in a tutorial when you'll have time ? :laugh:
Hello, yes !
I'm actually writing a GAPPS tuto, which is intensively tested by Zeksaine. Root will be added, as this is only a simple step inside the whole process.
This is a bit technical (read boring), but it worths the try. My TODO list is here: http://forum.xda-developers.com/showthread.php?t=2799404 , and while i'll take a little break, i hope soon to have custom recovery allowing you to directly flash gapps or supersu.
Yes ! I confirm ! Graveen has installed GAPPS on Thomoson THBK1 / Danew Dualboot tablet with sucess ! I'm not familiarised with linux environnement and realize it, but it requires some knowledges of linux command (coLinux especially)
Graveen is the only one users identified that it can put GAPPS on android environnement concerning this tablet.
Big thanks to him !
Graveen said:
Hello, yes !
I'm actually writing a GAPPS tuto, which is intensively tested by Zeksaine. Root will be added, as this is only a simple step inside the whole process.
This is a bit technical (read boring), but it worths the try. My TODO list is here: http://forum.xda-developers.com/showthread.php?t=2799404 , and while i'll take a little break, i hope soon to have custom recovery allowing you to directly flash gapps or supersu.
Click to expand...
Click to collapse
7600
I own a Cube U100GT and it's one of the many Chinese brothers of your THBK1-10. But mine came only with W 8.1.
I just start looking for a dual boot solution and I'm happy to know that it's is possible.
I don't need root for while, just play some games and apps.
So the original Android "ROM" of the tablet can do the job.
My version have 64Gb SSD and I've already resize the Win partition to make room for a new system.
Where can I look for a dual boot tuto and find this Android version?
Heya, can you post your partition list ?
What is the bios of your tablet ? Can you wire an USB keyboard to see this at boot ?
Basically, they effectively seems identical.
For partial update, you can find one here: http://www.danew.com/support-pilotes-manuels.php?type=218&produit=219 but it relies on existing android partitions i still have not dumped.
Android-x86 could worth a try also, although i doubt you will have all drivers (touch, gyro, etc..)
Graveen said:
Heya, can you post your partition list ?
What is the bios of your tablet ? Can you wire an USB keyboard to see this at boot ?
Basically, they effectively seems identical.
For partial update, you can find one here: but it relies on existing android partitions i still have not dumped.
Android-x86 could worth a try also, although i doubt you will have all drivers (touch, gyro, etc..)
Click to expand...
Click to collapse
The partition list is the standard for a windows installation (but no windows image on the end):
1: 300 Mb (Windows RE)
2: 100 Mb (System)
3: The rest (Windows). My SSD is 64Gb.
My tablet already comes with a dedicated keyboard cover, so I have full access to to UEFI Bios.
There's a lot of numbers:
Aptio Setup Utility Version 2.16.1242
Vendor - AMI
Core Version - 5.008
Project Version - 3BAGR 0.03
EC FW Version - 201401101A
Intel GOP driver - 7.0.1029
Sec RC Version - 00.05.00.00
TXE FW Version - 01.00.02.1060
I found the drivers pack for windows 8 and so I could install my PT-BR edition of W81. And reserve 20Gb at the end for another OS.
It's my first UEFI machine and I'm completely lost. There's a lot of options and I can't understand a quarter of that.
On the Tabletrepublic forum someone said that my bios recuse everything except a Windows pendrive. If is true, there's no way to put Android but changing/patching the UEFI.
Android x86 is for desktops right? And the Intel site, can I find Android images there?
Thank you. What i'll do is to check if my bios is identical to yours, because there are effectively numerous options. Then, i could finsh to dump my android partitions and let you play with them.
Honestly, the trick is the OS selection system, which is bring by the EFI bootloader (and certainly a dedicated partition). Once selection is done, another EFI bootloader (windows only) is called.
let's continue here: http://forum.xda-developers.com/showthread.php?t=2799404
- T R E B L E Y -
Android Partition Treblerizer
A tool able to seamlessly create / remove the vendor partition from within TWRP
INTRODUCTION
The creation of a tool able to create and remove the supplier partition from TWRP, so a computer was not required. So I created this flaming TWRP ZIP which can create and remove the vendor partition from the userdata system or partitions without a computer and without deleting the files in the mother partition in the recommended configuration.
Trebley, finally, also expands on our much loved Galaxy S8, bringing with it Project Treble on the much loved device.
The tool will try to resize the mother partition without deleting it, either during the creation and removal of the supplier partition. However, this can only be done when the mother partition is ext4, only when the supplier partition is at the end of the mother partition and when the mother partition is not encrypted. The recommended configuration is the one that is obtained by selecting the first option in each option: subdividing 512 MB from the end of the system partition. A reboot is required after applying the patch to the partition table because the kernel needs to reload it before doing anything else.
REQUIREMENTS
Due to the use of a key detection binary, it is compatible only with ARM and ARM64 devices running TWRP. So far I have tested it in the Samsung Galaxy S8 but It should work in any compatible device. I made it this way so other legacy devices could transition to Treble ROMs + GSI, and Android Pie. Please let me know about other devices using this tool!!!!!
INSTALLATION
WARNING, THIS SOFTWARE COULD WIPE ALL THE DATA IN YOUR DEVICE, INCLUDING THE INTERNAL STORAGE.
IT REQUIRES TWRP CUSTOM RECOVERY IN AN UNLOCKED DEVICE, OTHERWISE YOUR DEVICE COULD BE BRICKED AND IF YOU FOLLOW MY STEPS BELOW, YOU WILL LOSE YOUR WARRANTY, KNOX WILL DISPLAY 0x1! I'M NOT RESPONSIBLE FOR ANY DAMAGED DEVICE!.
!!! Whatever you do, it is at your own risk !!!
Either for creating or removing a vendor partition, follow these steps:
1. Download the TWRP ZIP tool to your External SD card.
2. Boot to TWRP recovery, under Install, flash the ZIP file as any other ROM or MOD file to execute the tool.
3. Reboot to recovery again to ensure the changes are applied properly.
4. In some cases you will need to format the mother partition after adding or removing the vendor partition next to it.
CREATE A VENDOR PARTITION:
So far these are the available options:
Mother partition selection: system / userdata
Split position: Splitting from the end / start of the mother partition.
Vendor partition size: 512 / 915 MB
REMOVE THE VENDOR PARTITION:
Should a Vendor module already exists, Trebley offers to remove it, returning to a Non-Treble partition table. It will return the space to the mother partition, system or userdata. So, older non Treble ROMs could be flashed after the mandatory reboot.
DOWNLOAD
Trebley_APT_v1.0_ARM_20190215-signed.zip
SOURCES
All rights reserved to the project: Party and its creator(@Oki).
CAUTION
Currently, we recommend the use of Trebley, exclusively to developers, as until now there has been no development of material related to the project treble, this project lays the foundations creating the partition vendor, for the support treble.
CREDITS
@someone755 for the keycheck binary
@Zackptg5 for the V4A install script that inspired my version.
@Oki for the base script.
XDA:DevDB Information
[PARTITION][TREBLE] Project Treble for Samsung Galaxy S8 [dreamltexx][15.02.2019], Tool/Utility for the Samsung Galaxy S8
Contributors
DarioRetr
Source Code: https://forum.xda-developers.com/axon-7/development/tool-party-v0-1-vendor-partition-t3831517
Version Information
Status: Alpha
Current Stable Version: V1.0
Stable Release Date: 2019-02-26
Current Beta Version: V0.5
Beta Release Date: 2019-02-15
Created 2019-02-17
Last Updated 2019-02-17
thx the tools makes me now easyer to create and remove my treble partition since i used for the moment all time parted with console on pc. for the one that thinks that is treble. without right vendor partition is useless. i have a partition that boots gsi but with a nice glitched display
geiti94 said:
thx the tools makes me now easyer to create and remove my treble partition since i used for the moment all time parted with console on pc. for the one that thinks that is treble. without right vendor partition is useless. i have a partition that boots gsi but with a nice glitched display
Click to expand...
Click to collapse
It is certainly not Trebley's fault, as it was specified in red, that Trebley is currently recommended for use only to developers, as Trebley, lays the foundations for Project Treble by creating the Vendor partition, after which it will be up to the developers Compile from source the vendor. IMG, the TWRP custom, and the kernel, to allow the startup of Project Treble.
In addition, in layman's terms, Trebley currently creates the vendor partition, after which it will be you dev compile the sources by adjusting them to the treble standards, to allow you to use project treble on the Samsung S8.
Members are reminded that making changes to device partitions is inherently dangerous. With that in mind, exercise caution and if in doubt, DON'T.
LenAsh said:
Members are reminded that making changes to device partitions is inherently dangerous. With that in mind, exercise caution and if in doubt, DON'T.
Click to expand...
Click to collapse
Dear @LenAsh, Trebley, precisely ensures through the scripts, a greater security, as it is all automated and calculated to the milimeter, and above all reduces the risk. Clearly, currently Trebley for S8, it is in its initial state, where it introduces the vendor partition, now it's up to you have developer, compile and propagate the material needed to start project treble in our Samsung S8 device
Any hope on this zip working on s8 phones? Or porting for others?
Rehvix said:
Any hope on this zip working on s8 phones? Or porting for others?
Click to expand...
Click to collapse
This zip is made for the Samsung Galaxy S8, but also works on other devices, because the script is multi platform and arm, currently, but we recommend the use of the zip file to developers, because currently Trebley creates only the vendor partition, but Without the vendor file, and a modified TWRP for treble support, you still can't use the project treble. We need to wait for some dev, compile from source, the appropriate kernel for project treble, and a vendor appropriate to the project treble along with a custom TWRP, allowing the Samsung S8 to use the vendor partition created by Trebley, and finally use Project Treble.
so can we get aosp room sir..??
onMyConquest said:
so can we get aosp room sir..??
Click to expand...
Click to collapse
In order to run a GSI, you have to wait for the scene, wait for some Dev, compile the kernel and the vendor, and place a custom twrp, to allow the project treble to go. In practice Trebley, prepares the partition making it compatible with Project Treble. Now you have to have developer share software, clearly depends on scene to scene, to give you an example on the Samsung Galaxy S6 Edge, with the same method, now they can use the GSI, with project treble.
Plz someon try this. Im afraid to brick
https://www.xda-developers.com/flash-generic-system-image-project-treble-device/
Can somebody take this down or at least force the guy to rename it ? this is clearly a script that'll only make an empty partition, this is NOT treble as stated in the thread also by reading the messages it's clear the OP doesn't know what he's talking about
If I understand, in the case of Galaxy S8, it splits the /system partition to create a /vendor partition and copy the contents from /system/vendor to the new /vendor partition, right?
However, dont the binaries and/or drivers need to be adapted for project Treble? I mean how does the (lets say) new aosp rom know what drivers use for each feature?
Josevega said:
Can somebody take this down or at least force the guy to rename it ? this is clearly a script that'll only make an empty partition, this is NOT treble as stated in the thread also by reading the messages it's clear the OP doesn't know what he's talking about
Click to expand...
Click to collapse
My dear, create the partition to make it compatible with the Project Treble, now instead of talking about things, why do not you go to work, adapting the kernel and the vendor, and send the vendor.img, and the boot.img and twrp .img, to be able to use project treble?
Also before saying, that Trebley, does not know what he is talking about, he learns to read English, why it is written clearly is round, that this script is recommended to use you have developer to ensure project treble also on S8.
If then you want to talk bad, because evidently put project treble on S8, it requires too much work as you have to move the device tree blob and so on, and for question of laziness you want to deny the possibility of having treble to users.
So we know that the developers of the scene samsung S8, does not paste them to adapt the kernel to project treble.
bamsbamx said:
If I understand, in the case of Galaxy S8, it splits the /system partition to create a /vendor partition and copy the contents from /system/vendor to the new /vendor partition, right?
However, dont the binaries and/or drivers need to be adapted for project Treble? I mean how does the (lets say) new aosp rom know what drivers use for each feature?
Click to expand...
Click to collapse
Then, Trebley, takes part of partition either from system or userdata, and then creates a new partition named vendor, and makes the device compatible with project treble, then it needs a developer, move device tree blobs, and systems the configuration , because it is not enough to move the vendor into vendor, you have to compile the kernel so that you take the drivers from the vendor, you have to do some work first at the software level.
You need someone who has Ubuntu, take the device sources from GitHub, and run the device tree, and compile the vendor.img and boot.img which includes the kernel, and then edit the twrp to make it compatible with Treble, after that you can use treble on the device.
Trebley, did not want to compile the vendor for the Samsung S8 users, for one reason, because Trebley's developers are external to the Samsung S8 scene, and compile a kernel or vendor for an S8, as you might compile for an S7 Edge or an S6, it could cause users of the S8, slowdowns, battery that you download easily, GSI where the camera does not work.
So we prefer to be your developer of the scene, to compile the vendor and boot, to ensure reliability even with the project treble. Because we do not want s8 users to consider project treble as an unstable project.
In addition, this project has also expanded on Note 8, we will see who will be faster to adapt kernels and vendors.
Update 18/02/2019
A developer of the S7 Edge scene, he decided to contribute to the project, starting to work on the sources of the device.
https://github.com/KiubeDev
Hello ,Can you make this for s7 edge?
DarioRetr said:
In addition, this project has also expanded on Note 8, we will see who will be faster to adapt kernels and vendors.
Update 18/02/2019
A developer of the S7 Edge scene, he decided to contribute to the project, starting to work on the sources of the device.
https://github.com/KiubeDev
Click to expand...
Click to collapse
In this github account all the repositories are forked from ivan meler, he is galaxy s7/edge developer i can see a universal exynos 8895 repo but there is no device specific code for dream2ltexx and only a highly experienced developer can make this then there will be no need for treble support.
Why are u not using the preload partition???? Would be much easier as its only used for apps to be installed in stock Rom for a carrier or Region...
Can I install this, and then https://forum.xda-developers.com/pr...vice-development/lineage-phh-treble-t3767690?
Will that brick?
qasim799 said:
In this github account all the repositories are forked from ivan meler, he is galaxy s7/edge developer i can see a universal exynos 8895 repo but there is no device specific code for dream2ltexx and only a highly experienced developer can make this then there will be no need for treble support.
Click to expand...
Click to collapse
Dear, that repository is another, he is just a dev, the repository where they are working and gitlab, and is only accessible to developers.
Hi everyone,
as title suggests, I'd like to "port" clean AOSP to be able to install and run it on the custom device.
Basically, the situation is following: I got a custom device, based on rockchip rk3288 SoC. The device currently runs Android 5.1 successfully. I'd like to update Android to version 6 (got AOSP sources and AWS builder image up and running), but the company that created Android v5 for us no longer exists.
Thus I am here to ask for advice(s) on how to proceed (or whether it even is a good idea to do that myself, given the fact that I have zero experience with Android ROMs development), possibly a step-by-step guide on what to do.
The question is, do I just find drivers for hardware components present in the device (usb hub, ethernet, etc.) and just somehow "link" those to existing sources (of AOSP) and just run the build with different parameters? Or do I need to build a whole new kernel for the given device-OS combination?
Thank you for any advice or opinion!
Well this is an interesting one. There are several routes you can take here.
If you have the kernel source code, and the source code for the drivers, you could probably build the kernel from source and use it to boot Android, however, as that's unlikely, you're looking at a more regular porting process, which usually consists of pulling the vendor blobs from the existing Android system, building AOSP/Lineage with those blobs involved, and hacking together a new ramdisk that HOPEFULLY will be compatible. It's a very long and very tedious process, but it's certainly possible.
From that you'll then get in to the debugging stage of finding out what works out of the box, you'll very well need to make changes to AOSP for it to work on that SoC.
abtekk said:
Well this is an interesting one. There are several routes you can take here.
If you have the kernel source code, and the source code for the drivers, you could probably build the kernel from source and use it to boot Android, however, as that's unlikely, you're looking at a more regular porting process, which usually consists of pulling the vendor blobs from the existing Android system, building AOSP/Lineage with those blobs involved, and hacking together a new ramdisk that HOPEFULLY will be compatible. It's a very long and very tedious process, but it's certainly possible.
From that you'll then get in to the debugging stage of finding out what works out of the box, you'll very well need to make changes to AOSP for it to work on that SoC.
Click to expand...
Click to collapse
Thanks for pointing in the right (or at least some) direction! I found some guide on porting ROMs which I followed, basically like you said. So I just replaced some files in System image. Will flash later today, so maybe I will get some results!
abtekk said:
From that you'll then get in to the debugging stage of finding out what works out of the box, you'll very well need to make changes to AOSP for it to work on that SoC.
Click to expand...
Click to collapse
So I was following this tutorial, although found some irregularities, let's say: For example, none of those 2 folders contained init.d/ directory, thus I didn't update it. Also, I haven't found META-INF folder therefore haven't updated updater-script.
Basically, when I did (or at least what I think I was doing was that I took /system partition from our current ROM, that is working on that custom device and replaced stuff in there by stuff from the new system I wanted to port. My idea from what I've read was that i took kernel (and boot/recovery) from the original, working ROM and "injected" the new system onto it. Is that correct? Is that what I needed to do? Because the problem is, I cannot boot into the system (might as well be because of Kernel version, because I am trying to port Android 6 on Kernel 3.10. which was used in the current ROM running Android 5). It looks like the device is stuck in bootloader, or "somehow doesn't know what to start" (sorry, I can't put it better), displaying only my device's logo.
When I connect it to the computer via USB cable, running adb devices shows me that device, but when I try to access shell using adb shell I got error saying that /system/bin/sh wasn't found, which made me thinking that somehow the /system partition isn't "linked" properly, like I stated in the beginning.
Was I doing everything correctly? Do I need to do something above that? (maybe do you know about some tutorial). I am trying to port AOSP 6 Android.
Thank you!