this might be a stupid question, but what is a kernel and how do u use them? i know what a rom is and how to install but not a kernel....
Wikipedia definition:
"In computing, the kernel is the central component of most computer operating systems; it is a bridge between applications and the actual data processing done at the hardware level. The kernel's responsibilities include managing the system's resources (the communication between hardware and software components).[1] Usually as a basic component of an operating system, a kernel can provide the lowest-level abstraction layer for the resources (especially processors and I/O devices) that application software must control to perform its function. It typically makes these facilities available to applicationprocesses through inter-process communication mechanisms and system calls."
Since Android is based on Linux: (don't know if this relevant)
"The Linux kernel is an operating system kernel used by the Linux family of Unix-like operating systems.[6] It is one of the most prominent examples of free and open source software.[7]
The Linux kernel is released under the GNU General Public License version 2 (GPLv2),[4] (plus some firmware images with various licenses), and is developed by contributors worldwide. Day-to-day development takes place on the Linux kernel mailing list.
The Linux kernel was initially conceived and created by Finnish computer science student[8] Linus Torvalds in 1991. Linux rapidly accumulated developers and users who adopted code from other free software projects for use with the new operating system.[9] The Linux kernel has received contributions from thousands of programmers.[10] Many Linux distributions have been released based upon the Linux kernel."
I have a question too.
When I boot ubuntu 10.04, the kernel comes up as 2.6.32, I think this is the same number as a previous android kernel. So how close is the android kernel to the linux kernel, us it a fork? When the new linux kernel comes out, will the android kernel be updated to reflect that?
What the little brown things are in a popcorn bag before you pop it XD
I thought it would be better to ask here than start a new thread but i have never installed a kernal before and was wondering how, do you just flash it in recovery? I have the desire rom and would like for my speaker to be a bit louder.
With kernels, I usually do ADB command.
liam.lah said:
So how close is the android kernel to the linux kernel, us it a fork?
Click to expand...
Click to collapse
It's the same with some Android and phone specific patches applied. A config file decides what architecture to build for and what drivers to include. That's what lets us bring in cutting edge features like compcache and BFS quickly.
Nice to think that your phone is running the exact same code that the world's fastest supercomputer is.
Hey guys,
As a software developer myself I feel a bit embarrassed that I need to ask this, but I really can't think of the answer myself. Here goes:
Why do we always need the latest sources from Samsung to be able to build an AOSP rom?
The way I see it, unless the kernel's internal APIs that Samsung's device drivers use have changed dramatically between, say, Froyo and Gingerbread, wouldn't it be possible to simply check out AOSP, paste the driver source files from Froyo into the appropriate folder in the kernel tree, and compile? Even if the kernel's internal APIs have changed a bit, they would be minor and well documented changes, so it should only be a moderately difficult task to fix the Froyo sources to work with Gingerbread. Sure, the drivers would still be "Froyo quality," but they seem to work pretty well to me. I'd be happy with a Gingerbread AOSP build w/ Froyo drivers.
It's kind of like what VMWare's tools do in a Linux guest OS - if you update your distro's kernel, the ABI is broken and you just recompile the modules. Same VMWare source code, different kernel, but it works.
I just searched ebay for RK3066 Development Board, and found one there, I have played the Beagle board.
this one seem good for play with RK3066 firmware and debug rom.
wy6688 said:
I just searched ebay for RK3066 Development Board, and found one there, I have played the Beagle board.
this one seem good for play with RK3066 firmware and debug rom.
Click to expand...
Click to collapse
Not used that one, but I'd caution you away from the RK3066 in general, as I have used a device with RK3066 chipset...
Rockchip don't respect or follow the GPL and give sources with binaries included. This means you cannot compile entirely from source, and can be problematic. Some core drivers like the clock driver are blobbed.
There may be better development boards out there, the ODroid X2 is one I've heard good things about.
I have checked the Latest Linux Kernel source from Kernel.org, all their source code included, using new ARM DTS system (device tree source), so you can compile all your kernel directly from mainstream kernel, except some board level chip driver, which you need to customize from Driver fold, /linux/arch/arm/boot/dts/rk3066a.dtsi, rk3066a-clocks.dtsi
wy6688 said:
I have checked the Latest Linux Kernel source from Kernel.org, all their source code included, using new ARM DTS system (device tree source), so you can compile all your kernel directly from mainstream kernel, except some board level chip driver, which you need to customize from Driver fold, /linux/arch/arm/boot/dts/rk3066a.dtsi, rk3066a-clocks.dtsi
Click to expand...
Click to collapse
Have you got NAND drivers for the rk3066 nand? clock drivers, ddr drivers?
(see files with a .uu extension, it's a uuencoded .o binary)
https://github.com/AndrewDB/rk3066-kernel/tree/master/arch/arm/mach-rk30 (ddr.uu, ddr_freq.uu, clock_data.uu)
https://github.com/AndrewDB/rk3066-kernel/tree/master/drivers/video (fb.uu)
I believe there's also some missing drivers for the nand (https://github.com/AndrewDB/rk3066-kernel/tree/master/drivers/mtd/rknand)
I just got the development broad from ebay and checked the source code, it do missing these source file and although you can build the kernel without issue for 3.0.8.
I believe the latest 3.10.x kernel from kernel org, which included the RK3066 DTS files, can be used to build the generic kernel that can run on RK3066 board and should have no other source code needed.
I'm trying to build this kernel based on 3.10.x, anyone know detail steps that build the generic kernel based on RK3066 DTS?
Thank advance.
Currently on hold due to working on Nougat first.
I've got a booting or should I say bootlooping build of Lineage 15.0 for I9000. (galaxysmtd)
I've had to use crazy hacks like adb binary from 7.1 in ramdisk.
Just to get `adb logcat` working.
For now it's stuck at bootlogo. I've attached the logcat here.
I'm looking into it to figure out what needs to be done.
Sources:
manifests and patches I've used.
https://github.com/galaxys1-resurrected/local_manifests
https://github.com/galaxys1-resurrected/android_patches
Kernel:
https://github.com/galaxys1-resurrected/android_kernel_samsung_aries
Device Tree:
https://github.com/galaxys1-resurrected/android_device_samsung_aries-common
https://github.com/galaxys1-resurrected/android_device_samsung_galaxysmtd
Thanks:
@rINanDO for backporting kernel side of things to 3.0
@xc-racer99 and @Coldwindofnowhere for getting the device upto android 7.1
And all others who had worked from beginning till now on this device.
Is there anyone still working on this?
I was curious if anyone this was still being developed? I'm totally newbie in the android scene but have some knowledge of operating systems and am interested in resurrecting my i9000.
I went through the logs and a couple of things jumped out:
1) Surface flinger returning non zero exit status because it needs OpenGL ES v2.0 or greater. I believe i9000's GPU PowerVR SGX540 supports OpenGL ES 2.0, so this issue could be solved.
2) Media extractor crash: /system/bin/mediaextractor: libminijail[1291]: prctl(PR_SET_NO_NEW_PRIVS): Invalid argument, whatever the heck it means.
3) activity_recognition HAL is deprecated, so ActivityRecognitionHardware class's init does not do anything.
For 3 , I got to android_hardware_location_ActivityRecognitionHardware.cpp's source where it comments out activity_recognition.h with the following comment:
Code:
// #include <hardware/activity_recognition.h>
// The activity recognition HAL is being deprecated. This means -
// i) Android framework code shall not depend on activity recognition
// being provided through the activity_recognition.h interface.
// ii) activity recognition HAL will not be binderized as the other HALs.
I believe more work has been done since this post based on git commits lasting upto Nov'17. Would be great if someone could post logs for an updated build. I feel that android oreo with go optimizations would be a really good fit for i9000 and uphold this device's legendary support. I mean a device running from eclair all the way to oreo would be amazing.
Even if this might not work out, I would like to thank @(°_o), @xc-racer99 , @Coldwindofnowhere and @rINanDO for bringing i9000 upto nougat. I believe even i9000's nexus sibling nexus s does not have a working nougat rom.
a1shakes said:
I was curious if anyone this was still being developed? I'm totally newbie in the android scene but have some knowledge of operating systems and am interested in resurrecting my i9000.
I went through the logs and a couple of things jumped out:
1) Surface flinger returning non zero exit status because it needs OpenGL ES v2.0 or greater. I believe i9000's GPU PowerVR SGX540 supports OpenGL ES 2.0, so this issue could be solved.
2) Media extractor crash: /system/bin/mediaextractor: libminijail[1291]: prctl(PR_SET_NO_NEW_PRIVS): Invalid argument, whatever the heck it means.
3) activity_recognition HAL is deprecated, so ActivityRecognitionHardware class's init does not do anything.
For 3 , I got to android_hardware_location_ActivityRecognitionHardware.cpp's source where it comments out activity_recognition.h with the following comment:
Code:
// #include <hardware/activity_recognition.h>
// The activity recognition HAL is being deprecated. This means -
// i) Android framework code shall not depend on activity recognition
// being provided through the activity_recognition.h interface.
// ii) activity recognition HAL will not be binderized as the other HALs.
I believe more work has been done since this post based on git commits lasting upto Nov'17. Would be great if someone could post logs for an updated build. I feel that android oreo with go optimizations would be a really good fit for i9000 and uphold this device's legendary support. I mean a device running from eclair all the way to oreo would be amazing.
Even if this might not work out, I would like to thank @(°_o), @xc-racer99 , @Coldwindofnowhere and @rINanDO for bringing i9000 upto nougat. I believe even i9000's nexus sibling nexus s does not have a working nougat rom.
Click to expand...
Click to collapse
Unfortunately, no one is really actively working on Oreo. As you've found out, it's an issue with the graphics drivers that is holding everything back. No device (that I've found) that uses a PowerVR graphics chip (we use the PowerVR SGX 540) has working graphics drivers on Oreo. There were rumours that someone had found newer working blobs, but weren't able to release them publicly due to intellectual property laws that they were trying to figure out (but this was months ago).
Our GPU does support sufficient enough OpenGL, but only using BGRA8888 as opposed to RGBA8888. BGRA hasn't officially been supported in Android since ~4.2, but there's been a hack used to make things work. Come Oreo, things have changed and the hack no longer applies cleanly. However, I think the really issue is that the gralloc blobs was extended by PowerVR (see https://github.com/xc-racer99/andro...6.0/exynos3/s5pc110/include/hal_public.h#L119) but with the binderized HALs/VNDK/other low-level Oreo changes something has broken. I had a go at trying to work around things, but failed too.
There are a few ways I can think of getting working graphics:
1) Someone finds some updated blobs for the PowerVR SGX 540 for ARM (I've found x86 ones, but they don't work for obvious reasons)
2) Someone hacks around the source code so that the blobs work - but I'm not sure if it's PowerVR "extension" of the gralloc interface that is causing issues or not...
3) We simply use software rendering, but this would be so slow with our ancient CPU that I haven't bothered to try
4) We work on porting a newer kernel so we have the Samsung DRM kernel driver, use the Linux PowerVR blobs coupled with drm_gralloc/drm_hwcomposer and maybe a wrapper like https://github.com/TexasInstruments/dri3wsegl and somehow cobble together working support
In terms of the mediaextractor crash, that's due to the kernel missing seccomp support. There's a whole bunch of different backports, some more successful than others. Due to our ancient kernel, backporting is no longer very easy...
If we could somehow get the graphics drivers working, we'd have a pretty good base as there are free implementations of all HALs/drivers except for GPS and TV-Out (and, of course, graphics....).
Are you really working on porting oreo on the i9000?
How do you deal with the small amount of ram?
Are you using the 'low end device' oreo feature?
nailyk said:
Are you really working on porting oreo on the i9000?
How do you deal with the small amount of ram?
Are you using the 'low end device' oreo feature?
Click to expand...
Click to collapse
No, no one (that I know of) is actively working on Oreo for the first-gen Galaxy S devices. There were attempts, the kernel got in good enough shape that everything wasn't immediately crashing, but due to the graphics driver issues described a couple posts ago nobody has managed to get a fully booting build.
xc-racer99 said:
No, no one (that I know of) is actively working on Oreo for the first-gen Galaxy S devices. There were attempts, the kernel got in good enough shape that everything wasn't immediately crashing, but due to the graphics driver issues described a couple posts ago nobody has managed to get a fully booting build.
Click to expand...
Click to collapse
Thanks for fast anwser. Yes, the graphic driver problem exist on another of my exynos device.
Anyway I wasn't able to boot the 7.1 (not able to boot something else than 2.3.6 )
Will attempt to see that post you are talking about but am probably not smart enough to deal with graphics drivers
Thanks for your time.
nailyk said:
Thanks for fast anwser. Yes, the graphic driver problem exist on another of my exynos device.
Anyway I wasn't able to boot the 7.1 (not able to boot something else than 2.3.6 )
Will attempt to see that post you are talking about but am probably not smart enough to deal with graphics drivers
Thanks for your time.
Click to expand...
Click to collapse
If you're serious about trying to mess with graphics drivers, it might be interesting to check out the blobs from https://www.renesas.com/pt-br/produ...ion-boards/renesas-starter-kit-for-rzg1e.html as it's an ARM-based device with the SGX540. It's possible that they're new enough to not run into the same issues as the older blobs (but equally possible that even the kernel part is closed source). The binary blobs are only semi-SoC specific as I've managed to use the OMAP blobs with only having hardware decoding being broken.
Is it for real???
I9000 !!
Apparently, some new SGX540 and SGX544 DDK blobs for OMAP4 have appeared:
https://gerrit.unlegacy-android.org/#/c/Unlegacy-Android/proprietary_vendor_ti/+/10525/
https://gerrit.unlegacy-android.org/#/q/topic:omap-ddk-1.14+(status:open+OR+status:merged
In fact, (Barnes and Noble's) hummingburd and ovation are both based on SGX544 and have gotten an Oreo ROM (using the new blobs).
https://forum.xda-developers.com/showpost.php?p=77526206&postcount=2490
Use android go it will be better.
MYEUHD said:
Apparently, some new SGX540 and SGX544 DDK blobs for OMAP4 have appeared:
https://gerrit.unlegacy-android.org/#/c/Unlegacy-Android/proprietary_vendor_ti/+/10525/
https://gerrit.unlegacy-android.org/#/q/topic:omap-ddk-1.14+(status:open+OR+status:merged
In fact, (Barnes and Noble's) hummingburd and ovation are both based on SGX544 and have gotten an Oreo ROM (using the new blobs).
https://forum.xda-developers.com/showpost.php?p=77526206&postcount=2490
Click to expand...
Click to collapse
Yep, I've seen the blobs, they've been there for awhile now. Just haven't had a chance to run a build with the blobs to see if they work. It's on my to-do list when I find the time
xc-racer99 said:
Yep, I've seen the blobs, they've been there for awhile now. Just haven't had a chance to run a build with the blobs to see if they work. It's on my to-do list when I find the time
Click to expand...
Click to collapse
Alright, I've had a chance to look at the blobs now. I have a build, but unfortunately it looks as if we need to adjust our hwcomposer as well We use a relatively old hwc 1.0 but the new gralloc blob doesn't appear to keep the framebuffer open which is a requirement for a hwcomposer this old. There is a prebuilt blob that is used by omap4 devices but it doesn't work on s5pc110 due to the fact that it uses some DSS stuff which is OMAP-specific. Still plenty of work to do, without even trying to figure out all the Oreo/Pie changes (I'm testing on KitKat as that's the build environment I have setup right now).
xc-racer99 said:
Alright, I've had a chance to look at the blobs now. I have a build, but unfortunately it looks as if we need to adjust our hwcomposer as well We use a relatively old hwc 1.0 but the new gralloc blob doesn't appear to keep the framebuffer open which is a requirement for a hwcomposer this old. There is a prebuilt blob that is used by omap4 devices but it doesn't work on s5pc110 due to the fact that it uses some DSS stuff which is OMAP-specific. Still plenty of work to do, without even trying to figure out all the Oreo/Pie changes (I'm testing on KitKat as that's the build environment I have setup right now).
Click to expand...
Click to collapse
We need a newer hwc anyway, as Pie requires at least hwc 1.3:
ChronoMonochrome said:
In 9.0, to get graphics to work, device is required to support HWC2 (or use either HWC2on1 or HWC2onFb adapters).
Click to expand...
Click to collapse
ChronoMonochrome said:
Yes, HWC has to be at least 1.3, to work with one of aforementioned adapters. With one of those adapters it will work like it was HWC 2 (but actually not exactly same).
Click to expand...
Click to collapse
As a reference, the galaxy S3's hwc was updated from 1.0 to 1.4: Thread
hardware/samsung
MYEUHD said:
We need a newer hwc anyway, as Pie requires at least hwc 1.3:
As a reference, the galaxy S3's hwc was updated from 1.0 to 1.4: Thread
hardware/samsung
Click to expand...
Click to collapse
Was unaware of the fact. Are you volunteering to make the patches?
I've uploaded my changes to https://github.com/xc-racer99/proprietary_vendor_samsung/tree/ddk-1.14 https://github.com/xc-racer99/android_hardware_samsung/tree/ddk-1.14 https://github.com/xc-racer99/android_kernel_samsung_aries/tree/ddk-1.14 https://github.com/xc-racer99/android_device_samsung_telusgalaxys4gmtd/tree/ddk-1.14 https://github.com/xc-racer99/android_device_samsung_aries-common/tree/ddk-1.14 but I think this might be the last I work on this as I don't really have the motivation to work on it anymore. Note the patches are against a custom version of Unlegacy Android 4.4 so you'll need to cherry pick the changes to your ROM of choice if desired.
The changes build, the EGL appears to initialize, but I always get
Code:
E/libEGL ( 471): validate_display:254 error 3008 (EGL_BAD_DISPLAY)
And in dmesg:
Code:
[ 8.509291] init: computing context for service '/system/vendor/bin/pvrsrvinit'
[ 8.509601] init: starting 'pvrsrvinit'
...
[ 8.601890] PVR_K: UM DDK-(4081762) and KM DDK-(4081762) match. [ OK ]
...
[ 8.765955] init: process 'pvrsrvinit', pid 99 exited
...
[ 55.560021] PVR_K:(Error): PVRSyncIOCTLCreate: Failed to find unused fd (-24)
[ 55.563491] PVR_K:(Error): PVRSyncIOCTLCreate: Failed to find unused fd (-24)
[ 55.597577] s3cfb s3cfb: [fb0] video memory released
Whether the issue is in the HWC or the gralloc blob that we've stolen from OMAP, I have no idea.
xc-racer99 said:
Was unaware of the fact. Are you volunteering to make the patches?
Click to expand...
Click to collapse
Will try to do my best!
BTW, do I really need jdk-7 to compile kitkat? or does it simply work with jdk-8??
MYEUHD said:
Will try to do my best!
BTW, do I really need jdk-7 to compile kitkat? or does it simply work with jdk-8??
Click to expand...
Click to collapse
You really do need jdk-7... I used the "reference implementation" available at http://jdk.java.net/java-se-ri/7 and made sure the java executables were in the PATH before the java I actually have installed.
Note that my Unlegacy Android trees will not work for the i9000 (well, they might, but you'd need to install u-boot as well at a bare minimum...)
It's kinda Insane that people are trying to get an 8 year phone to run oreo
@xc-racer99 Do you still have the AOSP 7.1 source code on your computer?
MYEUHD said:
@xc-racer99 Do you still have the AOSP 7.1 source code on your computer?
Click to expand...
Click to collapse
I've got the .repo folder, but don't have the individual files expanded as I don't have the disk space Could run a repo sync and look at things but don't have the disk space for a full build.
The_Pacific_gamer said:
It's kinda Insane that people are trying to get an 8 year phone to run oreo
Click to expand...
Click to collapse
its kinda insane that people are still using this phone.
I see installation instructions for a ROM (which is the Android OS, right?) and I see references to a kernel as well. What is the difference? Am I supposed to install both at the same time, or does the ROM carry the kernel, or how does it work?
Android is similar to mainstream linux operating systems in that the ROM is like the OS portion of a linux distro.
the Kernel is the portion that interfaces between the OS and the hardware.
Pretty much all Roms (there may be exceptions but I cant think of any) come prepackaged with a kernel as well.
so installing the ROM will install the kernel automatically and has the benefit of installing the kernel the developer intended.
There are separate Kernels available that have specific features you may prefer. (overclocking for CPU/GPU, specific modules loaded for emulation if running a linux distro within android etc.)
to install them you would install the rom (And its default kernel) then flash the kernel of your preference over it.
If you are just starting out I would just install the Rom and its default kernel unless you have a very specific use case.
hopefully that helps
There are often more pieces as well due to proprietary code:
ROM - the OS itself often either based on AOSP, the manufacturer software or Lineage (or a mix)
Kernel - refers to the open source linux kernel that controls hardware that it supports.
Firmware - includes manufacturer proprietary code for hardware that is not open source.
Modem - includes proprietary code for modem hardware.
it breaks down further but generally you will start with a stick manufacturer installation including all parts.
then you can flash a custom rom and kernel (Usally as a complete package)
Modem and firmware updates would still come from the manufacturer. (Most roms will tell you if a specific firmware or modem is needed, the modem usually doesnt matter as much anymore but in the early years it was important)
Thanks for the information!