how do i make an iso with 3.18 kernel?

[hatharry]

I have a gigabyte brix pro i am testing this on. Wifi does not work on kernel 3.10 but if i use kernel 3.18 it works fine.  i have downloaded the source, made an iso then added kernel 3.18 after install. is there a way to add the kernel when im making the the iso?

[Antony Stone]

http://www.android-x86.org/documents/customizekernel

Antony.

--
This email was created using 100% recycled electrons.

Please reply to the list;
please *don't* CC me.

[Mauro Rossi]

I had a similar question in mind, but slightly different,

if I had already the kernel image I would use the following command:

make iso_img TARGET_PRODUCT=android_x86 TARGET_PREBUILT_KERNEL=<path to the prebuilt kernel>

but in case I wanted to build kernel 3.18 how can I checkout android-3.18 head?

I have tried with following command in kernel folder, but I'm doing something wrong.

git checkout android-3.18

Last question, is the 3.18 kernel on the repo ready for compling or do I need to apply some patches?

Thanks

Mauro

[rbg]

I have compiled with the  on the repo(git) but had issues on boot of the iso.....(black screen)

moved on as was just seeing if it would build....that was about a week ago as I recall

[rbg]

should have said....

  on the android-x86 repo(git) which was populated with 3.18 a while back...

[Mauro Rossi]

Hi rbg, 

thanks for feedback, I was missing to fetch the new branch,

git fetch x86 android-3.18

Now I'm going off topic, my speciality :-) - but this will become related to kernel 3.18 because I'm going to try building  ISO with kernel 3.18 and the following mesa 10.3.5 and 10.4.0 hacks.

Mesa 10.3.5 and 10.4.0 for android_x86 and android_x86_64 targets

I have updated my 'not completely sane' github https://github.com/maurossi/mesa-mesa with mesa 10.3.5 and mesa 10.4.0 both "hacked to the bone" to build with x86_64 and with nouveau,

but I still have two problems...I did not yet figured how to solve, so I did "two fancy workarounds"...

The workarounds are not committed on github, because they belong to 'elf's realm' and I would like to really solve the problems, maybe someone with knowledge here may help me.

ISSUE 1) GENERATED files src/mesa/util needs to generate a source file format_srgb.c, which is used twice to build libmesa_util for Host and for Target.

There is no way I can complete build of x86 ISO and x86_64 ISO with current src/mesa/util/Android.mk, something very nasty is blocking the generation/compiling of the file, even by using $(local-generated-sources-dir) and $(local-host-generated-sources-dir) directives and $(transform-generated-sources)

If you clone the github you can avoid this issue by overwriting files in src/mesa/util with attached replacements, available also here:

http://www.mediafire.com/view/xd1ccujwsri33po/format_srgb.c

http://www.mediafire.com/download/v80zdvc4atqh5g8/Android.mk

ISSUE 2) TR1/unordered_set Not a new issue here,  mesa 10.3 and 10.4 use TR1 unordered_set instead of former lists to improve performance of Gallium nouveau. 

Problem is known since a few months, but I haven't figured yet how to solve it. We have options, but no solution yet...

opt0) Doing nothing: does not work because STLport 5.2.1 does not support the needed size_t types

opt1) Use C++11 standard templates bundled with gcc 4.9 <unordered_set>. Tried but no success.

opt2) Use <backward/hash_set> instead of <tr1/unordered_set>. Never tried that

opt3) Use <boost/unordered/set>, requires to just include some headers, but then there Bionic libc is not very nice again.

opt4) Hack bionic libc by defining just the needed unordered_set and hash functions

opt5) Use an enhanced STL, like EASTL. Not tried yet

If someone with knowlegde about this issues could help me, direct me, we could finally solve the problem and have nouveau enabled mesa 10.3.5  and 10.4.0 to play with kernel 3.18.

In the meantime the hack to avoid TR1/unordered_set problems, can only be to revert the related commits:

git revert fb4e23626f9f27c62aa1cbea05a1c8b088fcf49a

git revert bb06f2cd93e8e16798bd59b458abd8d33a8e4658

git revert eaa9e14ce5a3e69c6aa303f2e5f039c1cc0b8de1

git revert a9b21015f5e3a6a37e53a8b3c755519f7b70479e

For people those interested full explanations on how to build nouveau enabled ISO on github's README.md file

Happy Xmas to all Android-x86 google group

Mauro

[rbg]

what I have reverted to is using SOMEBODY's 10.1.4 mesa......

he had it just about perfect  and I am using that to try  and get it working with 5.0.2_r1

using your v2 changes where relevant....it'll be a while,,  then to try withh 3.18 kernel....

[rbg]

maybe you can git fetch it....I was on the day they updated it and did an  commit dif  and then did a snapshot

to grab it.....but whatever  works is what counts...

[Chih-Wei Huang]

2014-12-25 3:56 GMT+08:00 Mauro Rossi <issor...@gmail.com>:
> I had a similar question in mind, but slightly different,
>
> if I had already the kernel image I would use the following command:
>
> make iso_img TARGET_PRODUCT=android_x86 TARGET_PREBUILT_KERNEL=<path to the
> prebuilt kernel>
>
> but in case I wanted to build kernel 3.18 how can I checkout android-3.18
> head?
> I have tried with following command in kernel folder, but I'm doing
> something wrong.
>
> git checkout android-3.18

It's not ready for use.
Will announce once it's done.

[hatharry]

Does using make iso_img TARGET_PRODUCT=android_x86 TARGET_PREBUILT_KERNEL=<path to the prebuilt kernel> include the modules and firmware?

[pstglia]

Hi Mauro! How are you doing! Merry Xmas!

I played a bit with this today...

ISSUE 1) GENERATED files src/mesa/util needs to generate a source file format_srgb.c, which is used twice to build libmesa_util for Host and for Target.

There is no way I can complete build of x86 ISO and x86_64 ISO with current src/mesa/util/Android.mk, something very nasty is blocking the generation/compiling of the file, even by using $(local-generated-sources-dir) and $(local-host-generated-sources-dir) directives and $(transform-generated-sources)

I didn't have this problem. Just a warning during build

My lollipop branch is not the newest one (Downloaded on Nov/16). Is there any relation?

 

ISSUE 2) TR1/unordered_set Not a new issue here,  mesa 10.3 and 10.4 use TR1 unordered_set instead of former lists to improve performance of Gallium nouveau. 

opt1) Use C++11 standard templates bundled with gcc 4.9 <unordered_set>. Tried but no success.

Using a very insane procedure (just for testing ), I was able to compile tr1/unordered_set using "opt1". Here's what I did (using lollipop branch):

1) Created a directory under "external" and named it "maledeto_tr1"

2) Inside the created directory, created an "Android.mk" file with the following content (included gcc 4.9 lib as a prebuilt shared lib):

include $(CLEAR_VARS)

LOCAL_MODULE := libgnustl_shared

LOCAL_MODULE_TAGS := optional

LOCAL_SRC_FILES := /home/paulo/android_lollipop/prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/libgnustl_shared.so

LOCAL_MODULE_CLASS := SHARED_LIBRARIES

LOCAL_MODULE_SUFFIX := $(TARGET_SHLIB_SUFFIX)

include $(BUILD_PREBUILT)

3) Executed "mm" inside this directory to "build" the lib

4) Removed the directory "maledeto_tr1" from external (At first I wanted to keep it to automate this step, but had problems during linkage)

5) On external/mesa/Android.common.mk, added include paths to gcc 4.9 (absolute paths):

LOCAL_CPPFLAGS += \

        -Wno-error=non-virtual-dtor \

        -Wno-non-virtual-dtor \

        -Wno-error=return-type \

        -I/home/paulo/android_lollipop/prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/include \

        -I/home/paulo/android_lollipop/prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/include \

6) On external/mesa/src/gallium/drivers/nouveau/Android.mk, commented the include to libstlport:

#include external/stlport/libstlport.mk

7) On external/mesa/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp, removed namespace "std::" from isfinite function:

      case OP_MUL:

 if (i->dnz && i->dType == TYPE_F32) {

-    if (!std::isfinite(a->data.f32))

+    if (!isfinite(a->data.f32))

a->data.f32 = 0.0f;

-    if (!std::isfinite(b->data.f32))

+    if (!isfinite(b->data.f32))

b->data.f32 = 0.0f;

8) On external/mesa/src/egl/main/Android.mk, included libgnustl_shared (it's the shared library name used by gcc 4.9):

LOCAL_SHARED_LIBRARIES := \

        libglapi \

        libdl \

        libhardware \

        liblog \

        libcutils \

        libgralloc_drm \

        libgnustl_shared \

9) As I had compiling errors with os_munmap (this was changed recently as you probably noticed), I reverted to munmap on "external/mesa/src/gallium/winsys/radeon/drm/radeon_drm_bo.c":

-        os_munmap(bo->ptr, bo->base.size);

+        munmap(bo->ptr, bo->base.size);

Well, after all this mess I could compile it (at first with kernel 3.16 - later with kernel 3.18 rc6).

Tested on a Geforce 210 without gapps. It booted, but I didn't perform many tests (just changed language, played the bundled "flappy bird like" and connected Wi-FI ).

Seems smoth, but when tried to open Browser, system freezes. I believe this is related to the fact I haven't done a clean build.

That's it. I'm sharing just in case

Regards,

pstglia

[hatharry]

Figured it out. had to manually add modules and firmware. is there any time frame on when we can build kitkat with 3.18 from the git?

[György Pejović]

Hi everyone!

How can i swap the mouse's right click to be the long touch ?

[Mauro Rossi]

Hi pstglia,

I imagined that using C+11 templates available was possibile, but just imagined...
You DID IT!!!

We just need to use relative paths and for x86 build we're done!!!

I am also sending feedback and my latest finding about mesa 10.3.x and 10.4.0.
Most of problems I have are related to x86_64 build, for multiarch constraints in Android Build System, especially for generated files.

>>ISSUE 1) GENERATED files src/mesa/util needs to generate a source file format_srgb.c, which is used twice to build libmesa_util for Host and for Target.

>>There is no way I can complete build of x86 ISO and x86_64 ISO with current src/mesa/util/Android.mk, something very nasty is blocking the generation/compiling of the file, even by >>using $(local-generated-sources-dir) and $(local-host-generated-sources-dir) directives and $(transform-generated-sources)

>I didn't have this problem. Just a warning during build

>My lollipop branch is not the newest one (Downloaded on Nov/16). Is there any relation?

Did you see just warnings with x86 build?

It's because I have problems with x86_64 build, which implies multiarch libs, using the existing directive I had problems
-intermediates := $(call local-intermediates-dir,,$(LOCAL_2ND_ARCH_VAR_PREFIX))
+generated := $(call local-generated-sources-dir)

If I stick to just x86 iso, no multiarch, then the problem with compiling generated files does not appear, it is x86_64 problem, in my understanding.

The problem is also that $(call local-generated-sources-dir) is not retro-compatible with kitkat build system, I have tried with both my 10.3.5 and 10.4.0 github/maurossi/mesa-mesa and in order to build kitkat I had to revert to using $(call local-intermediates-dir)

>1) Created a directory under "external" and named it "maledeto_tr1"

It was really "cursed" for my level of understanding. :-)

>2) Inside the created directory, created an "Android.mk" file with the following content (included gcc 4.9 lib as a prebuilt shared lib):

>...

>6) On external/mesa/src/gallium/drivers/nouveau/Android.mk, commented the include to libstlport:

So we need libgnustl_shared module to replace libstlport module.

>LOCAL_CPPFLAGS += \

>        -Wno-error=non-virtual-dtor \

>        -Wno-non-virtual-dtor \

>        -Wno-error=return-type \

>        -I/home/paulo/android_lollipop/prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/include \

>        -I/home/paulo/android_lollipop/prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/include \

-Wno-error=return-type is important because for unknown cause with mesa 10.4.x return-type warnings started to be treated as errors
Could the include paths be relative and stay in LOCAL_C_INCLUDES for external/mesa/src/egl/main/Android.mk and ?

7) On external/mesa/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp, removed namespace "std::" from isfinite function:

This correction is an essential enabler for upstreaming the changes to mesa git, this was a show stopper.
Did libgnustl_shared also solved this, or was it solved natively by 4.9 g++?

9) As I had compiling errors with os_munmap (this was changed recently as you probably noticed), I reverted to munmap on "external/mesa/src/gallium/winsys/radeon/drm/radeon_drm_bo.c":

-        os_munmap(bo->ptr, bo->base.size);

+        munmap(bo->ptr, bo->base.size);

With x86_64 build I had made something similar by definining os_munmap(addr, length) = munmap(addr, length) at some point
there is something to review in drm/mesa code for mmap/munmap to have both 32 bit and multiarch compatibility.
I also had to modify external/drm in order to

>Tested on a Geforce 210 without gapps.

Did you notice that with lollipop even if dumpsys SurfaceFlinger shows gallium nouveau as OpenGL driver, in Settings -> About tablet you see just null drivers?

>That's it. I'm sharing just in case

Thank a lot and this is a new milestone you achieved. I was stuck for weeks.

Mauro


PS: about Nouveau plans,  is it necessary to complete drm_gralloc_nouveau.c with functions copied by xf86-video-nouveau?

Is there need for other functions (like sync-to-vblank and others) beyond my other lacks this is where I know the less.

Could we just use the original http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nv_accel_common.c code and pick some the essential functions?
But which are the essential ones?

[Chih-Wei Huang]

2014-12-27 19:07 GMT+08:00 Mauro Rossi <issor...@gmail.com>:
>
> Did you notice that with lollipop even if dumpsys SurfaceFlinger shows
> gallium nouveau as OpenGL driver, in Settings -> About tablet you see just
> null drivers?

The same for all (i915, i965, radeon...)
Not nouveau's fault.

I have looked the Settings's code.
Looks innocent.
Just can't understand why it can't get the
GL version like kitkat.
Probably need to dig deeper into the framework.


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[pstglia]

 

>1) Created a directory under "external" and named it "maledeto_tr1"

It was really "cursed" for my level of understanding. :-)

Sounds very hard to understand for me also (Believe me, I'm just a C/C++ hello world programmer :D - What I know a bit more are scripting, like shell, awk, etc ). I wasn't sure if I could include a prebuilt lib on the project, so started googling around and found these:

http://www.maxters.net/2012/05/adding-prebuilt-shared-library-to-android-build-system/

http://www.kandroid.org/ndk/docs/PREBUILTS.html

Also, I saw drm gralloc also accepts a prebuilt library (see hardware/drm_gralloc/Android.mk)

Used all these as base to proceed with this mess :)

 

>2) Inside the created directory, created an "Android.mk" file with the following content (included gcc 4.9 lib as a prebuilt shared lib):
>...
>6) On external/mesa/src/gallium/drivers/nouveau/Android.mk, commented the include to libstlport:

So we need libgnustl_shared module to replace libstlport module.

Right. If you keep it uncommented, you have conflicts due the same definitions in both. One of these conflicts is:

../prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/include/bits/stl_function.h:118:12: error: redefinition of 'struct std::binary_function<_Arg1, _Arg2, _Result>'

     struct binary_function

 

>LOCAL_CPPFLAGS += \

>        -Wno-error=non-virtual-dtor \

>        -Wno-non-virtual-dtor \

>        -Wno-error=return-type \

>        -I/home/paulo/android_lollipop/prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/include \

>        -I/home/paulo/android_lollipop/prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/include \

-Wno-error=return-type is important because for unknown cause with mesa 10.4.x return-type warnings started to be treated as errors
Could the include paths be relative and stay in LOCAL_C_INCLUDES for external/mesa/src/egl/main/Android.mk and ?

Probably relative paths will work. But the best option here would use some pre existing variable that points to this ( a GNULIBSTD_SOMETHING). So, we won't have to worry about 5.0, 5.1 in the future

And about LOCAL_C_INCLUDES: Just testing to be sure. If gallium drivers import these Android.mk (nouveau in particular) , should work.

Can you try this on?

 

7) On external/mesa/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp, removed namespace "std::" from isfinite function:

This correction is an essential enabler for upstreaming the changes to mesa git, this was a show stopper.
Did libgnustl_shared also solved this, or was it solved natively by 4.9 g++?

Well, what I know is when I switched to this "C++11/gcc 4.9/gnustl" (by the way, how do I call this?), I had this compiling error:

external/mesa/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp:419:20: error: expected unqualified-id before '(' token

          if (!std::isfinite(a->data.f32))

I supposed on stlport it had to be explicity references, while in "C++11/gcc 4.9/gnustl"  they are "exported" somehow. So I removed it

 

 

PS: about Nouveau plans,  is it necessary to complete drm_gralloc_nouveau.c with functions copied by xf86-video-nouveau?

Is there need for other functions (like sync-to-vblank and others) beyond my other lacks this is where I know the less.

Could we just use the original http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nv_accel_common.c code and pick some the essential functions?
But which are the essential ones?

I really would like to have the answer, but I don't, sorry. At this point, I'm trying random things.

My last bet some pre-init functions are necessary for proper function (like NVAccelInitNV50TCL on xf86-video-nouveau/src/nv50_accel.c, called by nv_accel_common.c). But this is just a guess more based on hope... :)

I'm trying to include it on gralloc to see what we got...

Regards,

pstglia

 

[Mauro Rossi]

Hi pstglia, this way of using gnustl just locally is amazing and, with your solution, we were not forced to change LOCAL_CC := $(TARGET_CC) -std=c99
M.

>Probably relative paths will work. But the best option here would use some pre existing variable that points to this ( a GNULIBSTD_SOMETHING). So, we won't have to worry about 5.0, 5.1 in the future

I modified external/gnustl/Android.mk with following relative paths, I had no error by Build System, we may need somthing different for multiarch, but for x86 it seams ok,
libgnustl_shared.so is delivered in target's /system/lib.

+LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := libgnustl_shared
LOCAL_MODULE_TAGS := optional

LOCAL_SRC_FILES :=  ../../prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/libgnustl_shared.so

LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_SUFFIX := $(TARGET_SHLIB_SUFFIX)

include $(BUILD_PREBUILT)

>And about LOCAL_C_INCLUDES: Just testing to be sure. If gallium drivers import these Android.mk (nouveau in particular) , should work.

>Can you try this on?

I tried in two ways adding LOCAL_C_INCLUDES and gallium nouveau was compiled in both ways.

1) Adding the include paths in top level Android.common.mk, instead of using LOCAL_CPPFLAGS include paths

LOCAL_C_INCLUDES += \
     $(MESA_TOP)/include
+    $(MESA_TOP)/../../prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/include \
+    $(MESA_TOP)/../../prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/include \


2) Adding the include paths in src/mesa/gallium/drivers/nouveau/Android.mk (and removing LOCAL_CPPFLAGS include paths in top level Android.common.mk)

LOCAL_C_INCLUDES := \
     $(MESA_TOP)/src \
     $(TARGET_OUT_HEADERS)/libdrm \
+    $(MESA_TOP)/../../prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/include \
+    $(MESA_TOP)/../../prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/include \

[pstglia]

Em sábado, 27 de dezembro de 2014 18h34min34s UTC-2, Mauro Rossi escreveu:

I modified external/gnustl/Android.mk with following relative paths, I had no error by Build System, we may need somthing different for multiarch, but for x86 it seams ok,
libgnustl_shared.so is delivered in target's /system/lib.

+LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := libgnustl_shared
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES :=  ../../prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/libgnustl_shared.so
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_SUFFIX := $(TARGET_SHLIB_SUFFIX)

include $(BUILD_PREBUILT)

According to this (http://www.drdobbs.com/cpp/accessing-c11-features-of-the-android-nd/240168385) we can use env variables "NDK_TOOLCHAIN_VERSION" and "LOCAL_C_INCLUDES". This could avoid in part the hardcoded path and version. Could you try this please?

LOCAL_SRC_FILES :=  ${ANDROID_NDK}/sources/cxx-stl/gnu-libstdc++/${NDK_TOOLCHAIN_VERSION}/libs/x86/libgnustl_shared.so

 

1) Adding the include paths in top level Android.common.mk, instead of using LOCAL_CPPFLAGS include paths

... 

2) Adding the include paths in src/mesa/gallium/drivers/nouveau/Android.mk (and removing LOCAL_CPPFLAGS include paths in top level Android.common.mk)

... 

+    $(MESA_TOP)/../../prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/include \
+    $(MESA_TOP)/../../prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/include \

The same as above here:

+    ${ANDROID_NDK}/sources/cxx-stl/gnu-libstdc++/${NDK_TOOLCHAIN_VERSION}/include \

 +    ${ANDROID_NDK}/sources/cxx-stl/gnu-libstdc++/${NDK_TOOLCHAIN_VERSION}/libs/x86/include \

Note: Using a variable for arch is also a good idea (x86 or x86_64).

[pstglia]

Just forget it... both these vars should be set prior to building. Not defined on building scripts...

[Mauro Rossi]

Hi,
I've tried building libgnustl_shared module by using NDK variables, but only ${TARGET_ARCH} is evaluated
M.


LOCAL_SRC_FILES :=  $(ANDROID_NDK)/sources/cxx-stl/gnu-libstdc++/${NDK_TOOLCHAIN_VERSION}/libs/${TARGET_ARCH}/libgnustl_shared.so



make: *** No rule to make target '//sources/cxx-stl/gnu-libstdc++//libs/x86/libgnustl_shared.so', needed by 'out/target/product/x86/obj/lib/libgnustl_shared.so'.  Stop.
make: Leaving directory '/home/utente/lollipop-x86'

#### make failed to build some targets (2 seconds) ####