This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Building from Source
#1
Hi All,
Dont suppose anyone knows the correct way to build the android image from source.
In order to get my waveshare 7 inch LCD hdmi panel to work correctly i have to make some changes to the following file in the uboot source (default resolution is 1280x720??)
android_u-boot/drivers/video/rockchip.c

Running Ubuntu 17.04 with Android Studio, JDK 8 and GCC installed.

---------------------------------------------------------------------------
As an update, with Lobo's post below I'm able to compile my own kernel using the following instructions. Lobo's help has fixed one issue, whereby the kernel wouldnt boot if the hdmi was connected, however still having difficulty with the correct display resolution. I believe its because the display doesnt return any valid EDID information and it fails to 1280x720.
As a contrast, Armbian does the same thing, except that when it fails it queries the resolution and sets correctly. Anyway, heres how i got it to compile if anyone else wants an beginners guide.

Install Requirements
Code:
sudo apt-get install -y openjdk-7-jdk
sudo apt-get install -y git ccache automake lzop bison gperf build-essential zip curl zlib1g-dev zlib1g-dev:i386 g++-multilib python-networkx libxml2-utils bzip2 libbz2-dev libbz2-1.0 libghc-bzlib-dev squashfs-tools pngcrush schedtool dpkg-dev liblz4-tool make optipng

Setup a Project Folder and use GIT to sync the kernel source
Code:
mkdir ~/Android
cd ~/Android
git clone https://github.com/TinkerBoard/android_kernel.git -b m-mr1-rk3288

Download and Extract the Toolchain
Code:
mkdir ~/Android/toolchain
wget https://releases.linaro.org/components/toolchain/binaries/4.9-2017.01/arm-linux-gnueabihf/gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf.tar.xz
tar -xvzf ./gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf.tar.xz -C ~/Android/toolchain
mv ~/Android/toolchain/gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf ~/Android/toolchain/arm-linux-gnueabihf

Make edits you want, then compile with below
Code:
export PATH=~/Android/toolchain/arm-linux-gnueabihf/bin:$PATH
export CROSS_COMPILE=~/Android/toolchain/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-
export ARCH=arm
cd ~/Android/android_kernel
make mrproper #This is just to cleanup if you have compiled before
make rockchip_defconfig -j4
make rk3288-miniarm.img -j4
[-] The following 1 user Likes lostangel556's post:
  • vivekb
Reply
#2
Yes, I also would like to have the whole source code. Hopefully Asus will publish soon.
But to change hdmi resolution it is not needed the android source code. I spent a lot of the last days to go through the rockchip hdmi kernel driver source code. The default resolution the driver uses, can be modified in drivers/video/rockchip/hdmi/rockchip-hdmi-lcdc.c. Yesterday I found the right timings for my 1280x800 7" display, that is connected via a M.NT68676 hdmi adapter board:
Code:
    {
        .mode = {
            .name = "1280x800p@60hz",
            .refresh = 60,
            .xres = 1280,
            .yres = 800,
            .pixclock = 85000000,
            .left_margin = 200,
            .right_margin = 72,
            .upper_margin = 22,
            .lower_margin = 3,
            .hsync_len = 128,
            .vsync_len = 6,
            .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
            .vmode = 0,
            .flag = 0,
        },
        .vic = HDMI_VIDEO_DMT | 11,  //512 | 11 = 523
        .vic_2nd = 0,
        .pixelrepeat = 1,
        .interface = OUT_P888,
    },

And in rockchip-hdmi.h can be set the default mode.
Code:
Edit:
#define HDMI_AUTO_CONFIG        false

/* HDMI default vide mode */
#define HDMI_VIDEO_DEFAULT_MODE            523 //1280x800

But this is not everything. The android window manager always uses the resolution 1920x1080. This works, but is not nice! Letters and symbols are very small. Don't work 'wm size 1280x800'. This produces misalignment of the touch panel area, for example in the center the touch is o.k. but the wider to the edge the bigger the misalignment. Or the 'wm density' causes cut symbols. The trick is, how to make the window manager use the physical resolution of your lcd display. First I thought it is inside the android code, but it is not. To find this, cost me several days.
In the device tree, in section rk_screen also is needed to definethe correct timings (rk3288-miniarm.dts):
Code:
/*Use own rk_screen config
#include "lcd-asus.dtsi"*/
.
.
.
&rk_screen {
    display-timings = <&disp_timings>;
    disp_timings: display-timings {
        native-mode = <&timing2>;
        timing0: timing0 {
            screen-type = <SCREEN_MIPI>;
            out-face  = <OUT_P888>;
            clock-frequency = <28488600>;
            hactive = <800>;
            vactive = <480>;
            hback-porch = <26>;
            hfront-porch = <85>;
            vback-porch = <21>;
            vfront-porch = <7>;
            hsync-len = <20>;
            vsync-len = <2>;
            hsync-active = <0>;
            vsync-active = <0>;
            de-active = <0>;
            pixelclk-active = <0>;
            swap-rb = <0>;
            swap-rg = <0>;
            swap-gb = <0>;
        };
        timing1: timing1 {
            screen-type = <SCREEN_RGB>;
            out-face    = <OUT_P888>;
            color-mode = <COLOR_YCBCR>;
            clock-frequency = <74250000>;
            hactive = <1024>;
            vactive = <600>;
            hback-porch = <160>;
            hfront-porch = <24>;
            vback-porch = <29>;
            vfront-porch = <3>;
            hsync-len = <136>;
            vsync-len = <6>;
            hsync-active = <1>;
            vsync-active = <1>;
            de-active = <0>;
            pixelclk-active = <0>;
            swap-rb = <0>;
            swap-rg = <0>;
            swap-gb = <0>;
        };
        timing2: timing2 {
            screen-type = <SCREEN_RGB>;
            out-face    = <OUT_P888>;
            color-mode = <COLOR_YCBCR>;
            clock-frequency = <83500000>;
            hactive = <1280>;
            vactive = <800>;
            hback-porch = <200>;
            hfront-porch = <72>;
            vback-porch = <22>;
            vfront-porch = <3>;
            hsync-len = <128>;
            vsync-len = <6>;
            hsync-active = <1>;
            vsync-active = <1>;
            de-active = <0>;
            pixelclk-active = <0>;
            swap-rb = <0>;
            swap-rg = <0>;
            swap-gb = <0>;
        };
        timing3: timing3 {
            screen-type = <SCREEN_RGB>;
            out-face    = <OUT_P888>;
            color-mode = <COLOR_YCBCR>;
            clock-frequency = <148500000>;
            hactive = <1920>;
            vactive = <1080>;
            hback-porch = <148>;
            hfront-porch = <88>;
            vback-porch = <36>;
            vfront-porch = <4>;
            hsync-len = <44>;
            vsync-len = <5>;
            hsync-active = <1>;
            vsync-active = <1>;
            de-active = <0>;
            pixelclk-active = <0>;
            swap-rb = <0>;
            swap-rg = <0>;
            swap-gb = <0>;
        };
    };
};


With this setting, the native-mode points to the 1280x800 timing, the framebuffer is initialized to this resolution. And this makes the window manager also use this resolution as physical resolution. Finally I changed the density from 240 to 180.
Reply
#3
(10-04-2017, 07:15 PM)lobo Wrote: Yes, I also would like to have the whole source code. Hopefully Asus will publish soon.
But to change hdmi resolution it is not needed the android source code. I spent a lot of the last days to go through the rockchip hdmi kernel driver source code. The default resolution the driver uses, can be modified in drivers/video/rockchip/hdmi/rockchip-hdmi-lcdc.c. Yesterday I found the right timings for my 1280x800 7" display, that is connected via a M.NT68676 hdmi adapter board:
Code:
    {
        .mode = {
            .name = "1280x800p@60hz",
            .refresh = 60,
            .xres = 1280,
            .yres = 800,
            .pixclock = 85000000,
            .left_margin = 200,
            .right_margin = 72,
            .upper_margin = 22,
            .lower_margin = 3,
            .hsync_len = 128,
            .vsync_len = 6,
            .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
            .vmode = 0,
            .flag = 0,
        },
        .vic = HDMI_VIDEO_DMT | 11,  //512 | 11 = 523
        .vic_2nd = 0,
        .pixelrepeat = 1,
        .interface = OUT_P888,
    },

And in rockchip-hdmi.h can be set the default mode.
Code:
/* HDMI default vide mode */
#define HDMI_VIDEO_DEFAULT_MODE            523 //1280x800

But this is not everything. The android window manager always uses the resolution 1920x1080. This works, but is not nice! Letters and symbols are very small. Don't work 'wm size 1280x800'. This produces misalignment of the touch panel area, for example in the center the touch is o.k. but the wider to the edge the bigger the misalignment. Or the 'wm density' causes cut symbols. The trick is, how to make the window manager use the physical resolution of your lcd display. First I thought it is inside the android code, but it is not. To find this, cost me several days.
In the device tree, in section rk_screen also is needed to definethe correct timings (rk3288-miniarm.dts):
Code:
/*Use own rk_screen config
#include "lcd-asus.dtsi"*/
.
.
.
&rk_screen {
    display-timings = <&disp_timings>;
    disp_timings: display-timings {
        native-mode = <&timing2>;
        timing0: timing0 {
            screen-type = <SCREEN_MIPI>;
            out-face  = <OUT_P888>;
            clock-frequency = <28488600>;
            hactive = <800>;
            vactive = <480>;
            hback-porch = <26>;
            hfront-porch = <85>;
            vback-porch = <21>;
            vfront-porch = <7>;
            hsync-len = <20>;
            vsync-len = <2>;
            hsync-active = <0>;
            vsync-active = <0>;
            de-active = <0>;
            pixelclk-active = <0>;
            swap-rb = <0>;
            swap-rg = <0>;
            swap-gb = <0>;
        };
        timing1: timing1 {
            screen-type = <SCREEN_RGB>;
            out-face    = <OUT_P888>;
            color-mode = <COLOR_YCBCR>;
            clock-frequency = <74250000>;
            hactive = <1024>;
            vactive = <600>;
            hback-porch = <160>;
            hfront-porch = <24>;
            vback-porch = <29>;
            vfront-porch = <3>;
            hsync-len = <136>;
            vsync-len = <6>;
            hsync-active = <1>;
            vsync-active = <1>;
            de-active = <0>;
            pixelclk-active = <0>;
            swap-rb = <0>;
            swap-rg = <0>;
            swap-gb = <0>;
        };
        timing2: timing2 {
            screen-type = <SCREEN_RGB>;
            out-face    = <OUT_P888>;
            color-mode = <COLOR_YCBCR>;
            clock-frequency = <83500000>;
            hactive = <1280>;
            vactive = <800>;
            hback-porch = <200>;
            hfront-porch = <72>;
            vback-porch = <22>;
            vfront-porch = <3>;
            hsync-len = <128>;
            vsync-len = <6>;
            hsync-active = <1>;
            vsync-active = <1>;
            de-active = <0>;
            pixelclk-active = <0>;
            swap-rb = <0>;
            swap-rg = <0>;
            swap-gb = <0>;
        };
        timing3: timing3 {
            screen-type = <SCREEN_RGB>;
            out-face    = <OUT_P888>;
            color-mode = <COLOR_YCBCR>;
            clock-frequency = <148500000>;
            hactive = <1920>;
            vactive = <1080>;
            hback-porch = <148>;
            hfront-porch = <88>;
            vback-porch = <36>;
            vfront-porch = <4>;
            hsync-len = <44>;
            vsync-len = <5>;
            hsync-active = <1>;
            vsync-active = <1>;
            de-active = <0>;
            pixelclk-active = <0>;
            swap-rb = <0>;
            swap-rg = <0>;
            swap-gb = <0>;
        };
    };
};


With this setting, the native-mode points to the 1280x800 timing, the framebuffer is initialized to this resolution. And this makes the window manager also use this resolution as physical resolution. Finally I changed the density from 240 to 180.

@lobo
you are my hero Big Grin

I had exactly the same problem with a 7" Display with max res. of 800x480.
The display controller tells me and also the HDMI Source Info in Android says that the resolution is 720x480 so it doesn't use the maximum resolution.
In the command shell of android i checked which physical resolution the Tinker Board is using and it told me the same like in your case 1920x1080.
But i changed the resolution manually in the shell by simply trying it out and so i ended up by resolution 1444x960 which worked best.
In this case the touch also worked best for me, so it was similar to the problem you had with the touch.

But now i will try your solution because i think this would be much more effectiv because in my case the resolution must be changed sometimes again because it doesn't hold it for a long time.

Do i need for editing this .h files android studio right?
So i have to open the .img from asus in there?

Dou you have problems with some apps which are automaticaly open in portrait mode?


Thanks a lot!
Reply
#4
Yes with portrait mode I have also problems. As I use Here app, the problem is that settings page stay blank in landscape mode, when I force portrait mode, the screen is only half, but stays in 90° as in landscape.

To compile this, you need the kernel sources, a armeabi toolchain, and a normal editor to edit the files. You can look here on my repository, there I have described how to do: https://github.com/joerg65/gpiomem_tinkerboard
Reply
#5
Yes thats exactly the same with Here App.
Okay thank you lobo i will try this today.
Reply
#6
The downloadlink for the toolchain is not working.
Also i don't know what i have to do when i want to modify the files so that they work with my display?

Greets
Reply
#7
(10-08-2017, 01:56 PM)Locke Wrote: The downloadlink for the toolchain is not working.
Also i don't know what i have to do when i want to modify the files so that they work with my display?

Greets

Indeed the link is broken. As I edited my readme it was working. When I am back from work I will try another, like Linaro or from Android SDK.
Reply
#8
Thanks for all the info guys, Going to give it a go when i get home from work.
Going to set the uboot default resolution to 640x480 so that the bootloader should be compatible with most monitors. Then the OS, Ill change default to 1280x720 for better support of most 16:9 displays.
Once this works ill setup my waveshare display at 1024x600 and report back
Reply
#9
(10-09-2017, 02:32 PM)lobo Wrote: @Locke: I tried this Linaro toolchain now, it compiled without error and also the kernel has booted: https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-eabi  [url=https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-eabi/][/url]
On my 64bit Linux machine I used the gcc-linaro-5.4.1-2017.05-x86_64_arm-eabi.tar.xz.

@lostangel556: Once you managed to flash the u-boot, please let us know. I tried to, was able to compile, but no success with flashing. The board always booted with the original version.

thank you lobo,
i see that i will need linux skills and of course skills how to use Git Hub Big Grin

I will try to get this work but i think i will need a bit time for that Big Grin


I am right that we will need the full source files from Asus to build our own Android Rom for our TB? because we allready have the Kernel source but the hardware files are missing right?
A big wish would be that we could port LineageOS for TB but i think this would take while^^

Greets
Reply
#10
@Locke: I tried this Linaro toolchain now, it compiled without error and also the kernel has booted: https://releases.linaro.org/components/t.../arm-eabi/
On my 64bit Linux machine I used the gcc-linaro-4.9.4-2017.01-x86_64_arm-eabi. I tried before with the 5.4.1 release, but the system freezes after some minutes. So it needs to be checked for a while, if it works stable with the 4.9.4 release.
There are also toolchains in the Android SDK, as "Sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi". You can try also with those, if you have already the SDK.


@lostangel556: Once you managed to flash the u-boot, please let us know. I tried to, was able to compile, but no success with flashing. The board always booted with the original version.

Update.
@Locke: I tried this Linaro toolchain now, it compiled without error and also the kernel has booted: https://releases.linaro.org/components/t.../arm-eabi/
On my 64bit Linux machine I used the gcc-linaro-4.9.4-2017.01-x86_64_arm-eabi. I tried before with the 5.4.1 release, but the system freezes after some minutes. So it needs to be checked for a while, if it works stable with the 4.9.4 release.
There are also toolchains in the Android SDK, as "Sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi". You can try with it also, if you have already the SDK.


@lostangel556: Once you managed to flash the u-boot, please let us know. I tried to, was able to compile, but no success with flashing. The board always booted with the original version.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)