Jump to content

Azq2

Members
  • Posts

    14
  • Joined

  • Last visited

Posts posted by Azq2

  1. Canon provides source code for cups driver, but with some proprietary binary libs.

    This libs available only for x86. No way for direct compiling cnijfilter for ARM (and other architectures). :(

     

    But we have qemu! We can transparently run x86 executables on any other host architectures.

     

    Easy steps to run cnijfilter on ARM (or any other arch):
    - Build https://github.com/endlessm/cnijfilter-common for x86

    - Copy all needed x86 libs using recursive ldd. And copy it to /usr/lib/bjlib/

    - Patch all executables: set interpreter to /usr/lib/bjlib/x86/ld-linux.so.2 and rpath to /usr/lib/bjlib/

    - Install these patched packages to ARM system

    - Install qemu-user and qemu-user-binfmt (or qemu-arm-static)

     

    You do not need to do this manually. I have implemented an automated build system: https://github.com/Azq2/cnijfilter-arm-build

     

    All you need is any x86 machine to do the build.

     

    How to use

    1. On any x86 machine:

     

    # Install dependencies
    sudo apt install debootstrap git util-linux
    
    # Get build system
    git clone https://github.com/Azq2/cnijfilter-arm-build
    
    # Start building
    cd cnijfilter-arm-build
    sudo ./build.sh build
    
    # Get .deb packages
    ls -lah ./result/full
    ls -lah ./result/light

     

    After build we have two variants of packages: full and light

     

    Item Full Light

    PPD files

    + +

    CUPS filters

    + +

    CUPS backends

    + -
    lgmon + -

    canon-maintenance

    + -
    cngpij + -
    cngpijmnt + -
    cnijlgmon2 + -
    cnijnetprn + -
    cnijnpr + -
    docs + -

     

    In most cases, a light package is completely sufficient:

    - We don't need canon usb backend, because cups have builtin USB support

    - We don't need canon network backend, because cups have builtin BJNP support (package cups-backend-bjnp)

    - Other canon maintenance utils are useless (in my opinion)

     

    2. Copy .deb from result/light or result/full to your ARM machine.

     

    3. On your ARM machine:

     

    # Install dependencies
    sudo apt install qemu-user qemu-user-binfmt # or sudo apt install qemu-user-static
    
    # Install common for all printers package
    sudo dpkg -i cnijfilter-common.deb
    
    # Install printer-specific package
    # Choose right package for your printer! e400series only for reference!
    sudo dpkg -i cnijfilter-e400series.deb

     

    4. Done. You can now configure CUPS.

     

    Security with apparmor (optional)

     

    CUPS filters don't need any specific permissions.

     

    Create file /etc/apparmor.d/cnijfilter-filters with contents:

     

    #include <tunables/global>
    
    /usr/bin/bjfilter* {
    	#include <abstractions/base>
    	@{PROC}/sys/vm/mmap_min_addr r,
    }
    
    /usr/bin/cif[a-z]*[0-9d]* {
    	#include <abstractions/base>
    	@{PROC}/sys/vm/mmap_min_addr r,
    }
    
    /usr/lib/cups/filter/{cmdtocanonij,pstocanonbj,pstocanonij} {
    	#include <abstractions/base>
    	@{PROC}/sys/vm/mmap_min_addr r,
    }

     

    Then restart apparmor:

     

    sudo systemctl reload apparmor
    sudo aa-enforce cnijfilter-filters

     

    Note: this minimal file full coverage all executables in light package. For full package you need write additional rules by yourself.

  2. Please, don't forget delete test user for ssh:

    userdel -f test222

     

    Also, i released image without openssh and "test222" user: https://zhumar.in/Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop_v3.zip

    Not official. Only for test. As own risk.

    If any other users with same problem want to test this image.

    Until it is fixed in the official release (in progress). 

     

    sha256: 377040dd9c42beaec1531199099d0eb12a547cab3f4e761801bbe1c20afe00b1

  3. 1 hour ago, WZ9V said:

    Yes.  PC running Linux Mint 19

    # Install required software
    sudo apt install parted qemu binfmt-support qemu-user-static
    
    # Mount armbian image
    sudo losetup /dev/loop0 Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop.img
    sudo partprobe /dev/loop0
    sudo mount /dev/loop0p1 /mnt
    
    # Copy qemu static binary for arm chrooting
    sudo cp -pR /usr/bin/qemu-arm-static /mnt/usr/bin/qemu-arm-static
    
    # From dir, where you place downloaded debs
    sudo cp linux-image-rockchip_5.77_armhf.deb dpkg linux-dtb-rockchip_5.77_armhf.deb /mnt/tmp
    
    # Mount system dirs and go chroot
    cd /mnt
    sudo mount -t devtmpfs dev dev
    sudo mount -t sysfs sys sys
    sudo mount -t devpts dev/pts dev/pts
    sudo mount -t proc proc proc
    sudo chroot .
    
    # Now we in arm chroot.
    
    # Do magic
    mv /bin/sync /bin/sync2
    ln -s /bin/true /bin/sync
    
    # Remove "next"
    dpkg -r linux-dtb-next-rockchip linux-image-next-rockchip
    
    # Do install required debs.
    dpkg -i /tmp/*.deb
    
    # Optional: you can install openssh-server in this step...
    # apt install openssh-server
    # adduser test222
    # passwd test222
    # usermod -G sudo -a test222
    
    # Undo magic
    rm /bin/sync
    mv /bin/sync2 /bin/sync
    
    # Go to host
    exit
    
    # Now we in host
    
    # Unmount image
    sudo umount /mnt/*/*
    sudo umount /mnt/*
    cd /
    sudo umount /mnt
    sudo sync
    
    # Done. Flash Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop.img to your tinkerboard.

     

  4. Hi!

    I connect my 1366x768 monitor to Tinkerboard, but resolution sets to 1280x720. 

     

    $ xrandr
    Screen 0: minimum 320 x 200, current 1280 x 720, maximum 8192 x 8192
    HDMI-1 connected 1280x720+0+0 (normal left inverted right x axis y axis) 410mm x 230mm
    1920x1080 60.00 +
    1280x720 60.00*
    720x480 60.00

     

    Yes, i tried set timings manualy. I set native from edid:

    Modeline "Mode 0" 85.50 1366 1436 1579 1792 768 771 774 798 +hsync +vsync

     

    But after applying this modeline:

    - monitor detects 1280x720 resolution instead of 1366x768

    - crops image as 1024x768

    - have many noises and waves on screen... very unstable image
    (pixel clock 84.857 mhz, but expected 85.5 mhz)

     

    I tried use modelines but result is one - not working.

     

    Why it happens? Answer is simple: https://github.com/TinkerBoard/debian_kernel/blob/e57365482d2e2e5105d9d368eca432248fcf92a2/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#L2273

    	/*
    	 * Hdmi or DisplayPort request a Accurate clock.
    	 */
    	if (output_type == DRM_MODE_CONNECTOR_HDMIA ||
    	    output_type == DRM_MODE_CONNECTOR_DisplayPort)
    		if (clock != request_clock) // see this
    			return MODE_CLOCK_RANGE;

     

    Clock for HDMI must be set without any deviations. 

    And this is the very reason why 1366x768 not listed in xrandr. 

     

    But setting manual timings with xrandr omits this check. But not works too. Why? 

    Here the answer was also simple. 

     

    I added debug to hdmi_av_composer() for dump actual mpixelclock. 

    And i set manual timings like this:

     

    pNJxyFiYiko.thumb.jpg.0d673fcfd63bca3ed849b11eb5fc0138.jpg

     

    Debug for this timings:

    [ 152.196219] hdisplay = 1366 pixel
    [ 152.196224] vdisplay = 768 lines
    
    // Front porch
    [ 152.196231] h_de_hs = 70 pixel clks
    
    // hsync len
    [ 152.196236] hsync_len = 143 pixel clks
    
    // back porch
    [ 152.196226] hblank = 426 pixel - (143 + 70) = 213
    
    // Front porch
    [ 152.196234] v_de_vs = 3 lines
    
    // vsync len
    [ 152.196238] vsync_len = 3 lines
    
    // back porch
    [ 152.196229] vblank = 30 pixel - 6 = 24
    
    // pixel clock
    [ 152.196241] vmode->mpixelclock = 84857000 hz
    [ 152.196243] vmode->mtmdsclock = 84857000 hz

    And what do we see?

    All is well, except pixel clock. I set 85.5 MHz, but driver set 84.857 MHz. WTF?

    0.643 Mhz difference, Karl!

     

    What does it mean? PLL can't calculate dividers for wanted DCLK frequency. 

     

    Okay, after few day of research i randomly checked TinkerOS. And it works:
     

    azq2@tinkerboard:~$ xrandr
    Screen 0: minimum 320 x 200, current 1280 x 720, maximum 8192 x 8192
    HDMI-1 connected 1280x720+0+0 (normal left inverted right x axis y axis) 410mm x 230mm
    1366x768 59.79 +
    1920x1080 60.00 59.94 
    1152x864 75.00 
    1280x720 60.00* 59.94 
    1152x720 59.97 
    1024x768 75.03 60.00 
    832x624 74.55 
    800x600 75.00 60.32 
    720x480 60.00 59.94 
    640x480 75.00 60.00 59.94 
    720x400 70.08

    O_O WTF???

    This is a bug of Armbian maintainers...? (spoiler: It turned out that yes -_-)

     

    I checked all patches that affect dw hdmi or VOP. 

    And I found a problem. 

     

    In commit 93ae28f78dce6c747f0616dced591af7edf31377 maintainer igorpecovnik upgrades kernel and for some strange reasons disables very important patch 01-linux-0005-dts.patch

    But this patch contains important changes for HDMI:

     

    +static struct rockchip_pll_rate_table rk3288_npll_rates[] = {
    +	RK3066_PLL_RATE_NB(594000000, 1, 99, 4, 32),
    +	RK3066_PLL_RATE_NB(585000000, 6, 585, 4, 32),
    +	RK3066_PLL_RATE_NB(432000000, 3, 216, 4, 32),
    +	RK3066_PLL_RATE_NB(426000000, 3, 213, 4, 32),
    +	RK3066_PLL_RATE_NB(400000000, 1, 100, 6, 32),
    +	RK3066_PLL_RATE_NB(342000000, 3, 171, 4, 32),
    +	RK3066_PLL_RATE_NB(297000000, 2, 198, 8, 16),
    +	RK3066_PLL_RATE_NB(270000000, 1, 135, 12, 32),
    +	RK3066_PLL_RATE_NB(260000000, 1, 130, 12, 32),
    +	RK3066_PLL_RATE_NB(148500000, 1, 99, 16, 32),
    +	RK3066_PLL_RATE(148352000, 13, 1125, 14),
    +	RK3066_PLL_RATE_NB(146250000, 6, 585, 16, 32),
    +	RK3066_PLL_RATE_NB(108000000, 1, 54, 12, 32),
    +	RK3066_PLL_RATE_NB(106500000, 4, 213, 12, 32),
    +	RK3066_PLL_RATE_NB(85500000, 4, 171, 12, 32),
    +	RK3066_PLL_RATE_NB(74250000, 4, 198, 16, 32),
    +	RK3066_PLL_RATE(74176000, 26, 1125, 14),
    +	{ /* sentinel */ },
    +};
    +
     #define RK3288_DIV_ACLK_CORE_M0_MASK	0xf
     #define RK3288_DIV_ACLK_CORE_M0_SHIFT	0
     #define RK3288_DIV_ACLK_CORE_MP_MASK	0xf
    @@ -214,7 +235,7 @@ static struct rockchip_pll_clock rk3288_pll_clks[] __initdata = {
     	[gpll] = PLL(pll_rk3066, PLL_GPLL, "gpll", mux_pll_p, 0, RK3288_PLL_CON(12),
     		     RK3288_MODE_CON, 12, 8, 0, rk3288_pll_rates),
     	[npll] = PLL(pll_rk3066, PLL_NPLL, "npll",  mux_pll_p, 0, RK3288_PLL_CON(16),
    -		     RK3288_MODE_CON, 14, 9, ROCKCHIP_PLL_SYNC_RATE, rk3288_pll_rates),
    +		     RK3288_MODE_CON, 14, 9, 0, rk3288_npll_rates),
     };

    It adds additional dividers for npll (used as source for DCLK). For exmaple, 85500000 needed for me. 

    After applying this patch my problem resolved. All resolutions determinted and monitor works normal. 

     

    root@tinkerboard:~# cat /sys/devices/platform/display-subsystem/drm/card0/card0-HDMI-A-1/modes
    1366x768p60
    1920x1080p60
    1920x1080p60
    1152x864p75
    1280x720p60
    1280x720p60
    1024x768p75
    1024x768p60
    800x600p75
    800x600p60
    640x480p75
    720x400p70

     

    I send pull request https://github.com/armbian/build/pull/1317

    I'm not sure that he will be accepted.

     

    I created this topic for tinkerboard users with same problem. This patch helped me. 

     

    You can manualy build kernel with this patch (needed ubuntu bionic as host system):

    git clone https://github.com/armbian/build
    cd build
    wget https://patch-diff.githubusercontent.com/raw/armbian/build/pull/1317.patch -O 1317.patch
    patch -p1 < 1317.patch
    sudo ./compile.sh BOARD=tinkerboard BRANCH=default KERNEL_ONLY=yes RELEASE=bionic NO_APT_CACHER=yes BUILD_KSRC=no

     

    P.S. The commit description speaks for itself :)

     

    Quote

    Rockchip/Tinkerboard default patches fixes. It compiles now but haven't check in details wheather disabled are still needed.

     

    Debs for test:

    linux-image-rockchip_5.77_armhf.deb

    linux-dtb-rockchip_5.77_armhf.deb

     

    Or image with installed patched debs:https://zhumar.in/Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop_v3.zip

    sha256: 377040dd9c42beaec1531199099d0eb12a547cab3f4e761801bbe1c20afe00b1

     

    Not official. Only for test. Use this as own risk.

  5. I have same problem. You have two ways:

     

    1. Try set timings manualy. Find in /var/log/Xorg.0.log right modeline and add it to xrandr. 

    # CVT
    xrandr --newmode "1920x1200_cvt"  193.25  1920 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync
    xrandr --addmode HDMI-1 "1920x1200_cvt"
    xrandr --output HDMI-1 --mode "1920x1200_cvt"
    
    # if not working - GTF
    xrandr --newmode "1920x1200_gtf"  193.16  1920 2048 2256 2592  1200 1201 1204 1242  -HSync +Vsync
    xrandr --addmode HDMI-1 "1920x1200_gtf"
    xrandr --output HDMI-1 --mode "1920x1200_gtf"
    
    # or you can find right timings in /var/log/Xorg.0.log

     

    2. If not working - try my pull request for 4.4 kernel: https://github.com/armbian/build/pull/1317

  6. I have same problem. You have two ways:

     

    1. Try set timings manualy. Find in /var/log/Xorg.0.log right modeline and add it to xrandr. 

    # CVT
    xrandr --newmode "1920x1200_cvt"  193.25  1920 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync
    xrandr --addmode HDMI-1 "1920x1200_cvt"
    xrandr --output HDMI-1 --mode "1920x1200_cvt"
    
    # if not working - GTF
    xrandr --newmode "1920x1200_gtf"  193.16  1920 2048 2256 2592  1200 1201 1204 1242  -HSync +Vsync
    xrandr --addmode HDMI-1 "1920x1200_gtf"
    xrandr --output HDMI-1 --mode "1920x1200_gtf"
    
    # or you can find right timings in /var/log/Xorg.0.log

     

    2. If not working - try my pull request for 4.4 kernel: https://github.com/armbian/build/pull/1317

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines