March 2015 - Dev - lists.linaro.org

by Peter Griffin

Hi folks, For fun I've done a minimal U-Boot port for the HiKey board, I thought I'd post it here in case anyone else is interested. This work is based on top of Linus Walleij Juno port. The code can be found here: - ssh://git@git.linaro.org:/people/peter.griffin/u-boot Currently the port supports: - 1) Serial 2) eMMC (although only basic read testing) 3) USB (ASIX usb networking works, no mass storage) 4) GPIO So you have ATF -> u-boot -> kernel / your_own_rtos The main "useful" thing I suppose is the ability to quickly tftp kernels etc into DDR over the network. Obviously the ability to toggle the LEDs in u-boot is also something to amuse yourself with. Pre-built binaries can be found here: - http://people.linaro.org/~peter.griffin/hikey/hikey-u-boot-release_r1/ NB: These are built with the latest PSCI enabled ATF, so you also need to use the corresponding PSCI enabled kernel to get all 8 cores. The readme on how to replicate everything from source can be found here: - http://people.linaro.org/~peter.griffin/hikey/hikey-u-boot-release_r1/u-boo… . Any patches please send them along to me, one obvious missing feature is sdhci support. That doesn't look very hard to get going, as long as we can get the IP clocked and out of reset (and would be significantly easier if the published datasheet documented the registers...). Have Fun! regards, Peter. p.s. serial trace below debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1! Switch to aarch64 mode. CPU0 executes at 0xf9801000! NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):9a97502 NOTICE: BL1: Built : 08:13:36, Mar 10 2015 NOTICE: succeed to init lpddr3 rank0 dram phy INFO: lpddr3_freq_init, set ddrc 533mhz INFO: init ddr3 rank0 in 533MHz INFO: ddr3 rank1 init pass in 533MHz INFO: Elpida DDR NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.1(debug):9a97502 NOTICE: BL2: Built : 10:22:35, Mar 17 2015 INFO: BL2: Loading BL3-1 INFO: Using FIP INFO: Loading file 'bl31.bin' at address 0xf9858000 INFO: File 'bl31.bin' loaded: 0xf9858000 - 0xf985f010 INFO: BL2: Loading BL3-3 INFO: Using FIP INFO: Loading file 'bl33.bin' at address 0x37000000 INFO: File 'bl33.bin' loaded: 0x37000000 - 0x3703db38 NOTICE: BL1: Booting BL3-1 NOTICE: BL3-1: v1.1(debug):9a97502 NOTICE: BL3-1: Built : 10:22:38, Mar 17 2015 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x37000000 INFO: BL3-1: Next image spsr = 0x3c9 U-Boot 2015.04-rc1-00010-g49ec0dd (Mar 17 2015 - 10:11:00) hikey_aemv8a DRAM: 1 GiB MMC: HiKey DWMMC: 0 Using default environment In: serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 HiKey64# usb start starting USB... USB0: Core Release: 3.00a scanning bus 0 for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... Warning: asx0 using MAC address from net device 1 Ethernet Device(s) found HiKey64# HiKey64# setenv ipaddr 192.168.0.200 HiKey64# HiKey64# setenv serverip 192.168.0.10 HiKey64# HiKey64# tftpboot 0x10000000 Image Using asx0 device TFTP from server 192.168.0.10; our IP address is 192.168.0.200 Filename 'Image'. Load address: 0x10000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################################T ########### ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############################################## 238.3 KiB/s done Bytes transferred = 12214232 (ba5fd8 hex) HiKey64# tftpboot 0x13000000 hi6220-hikey.dtb Using asx0 device TFTP from server 192.168.0.10; our IP address is 192.168.0.200 Filename 'hi6220-hikey.dtb'. Load address: 0x13000000 Loading: ################# 237.3 KiB/s done Bytes transferred = 85319 (14d47 hex) HiKey64# ï¿½ooti 0x10000000 - 0x13000000 Unknown command 'ï¿½ooti' - try 'help' HiKey64# Unknown command 'ï¿½ooti' - try 'help' HiKey64# booti 0x10000000 - 0x13000000 ## Flattened Device Tree blob at 13000000 Booting using the fdt blob at 0x13000000 Using Device Tree in place at 0000000013000000, end 0000000013017d46 Starting kernel ... [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.18.0+ (griffinp@griffinp-ThinkPad-X1-Carbon-2nd) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #5 SMP PREEMPT Tue Mar 17 08:21:27 GMT 2015 [ 0.000000] CPU: AArch64 Processor [410fd033] revision 3 [ 0.000000] Detected VIPT I-cache on CPU0 [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: UEFI not found. [ 0.000000] cma: Reserved 16 MiB at 0x000000003f000000 [ 0.000000] On node 0 totalpages: 262144 [ 0.000000] DMA zone: 3584 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 262144 pages, LIFO batch:31 [ 0.000000] psci: probing for conduit method from DT. [ 0.000000] psci: PSCIv1.0 detected in firmware. [ 0.000000] psci: Using standard PSCI v0.2 function IDs [ 0.000000] PERCPU: Embedded 14 pages/cpu @ffffffc03eefc000 s18688 r8192 d30464 u57344 [ 0.000000] pcpu-alloc: s18688 r8192 d30464 u57344 alloc=14*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 258560 [ 0.000000] Kernel command line: console=ttyAMA0,115200n8 root=/dev/sda1 rw earlyprintk=pl011,0x7ff80000 debug user_debug=31 loglevel=9 [ 0.000000] log_buf_len individual max cpu contribution: 4096 bytes [ 0.000000] log_buf_len total cpu_extra contributions: 28672 bytes [ 0.000000] log_buf_len min size: 16384 bytes [ 0.000000] log_buf_len: 65536 bytes [ 0.000000] early log buf free: 14752(90%) [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) [ 0.000000] Memory: 994464K/1048576K available (7777K kernel code, 651K rwdata, 3116K rodata, 376K init, 492K bss, 54112K reserved) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vmalloc : 0xffffff8000000000 - 0xffffffbdffff0000 ( 247 GB) [ 0.000000] vmemmap : 0xffffffbe00000000 - 0xffffffbfc0000000 ( 7 GB maximum) [ 0.000000] 0xffffffbe00000000 - 0xffffffbe00e00000 ( 14 MB actual) [ 0.000000] PCI I/O : 0xffffffbffa000000 - 0xffffffbffb000000 ( 16 MB) [ 0.000000] fixed : 0xffffffbffbdfe000 - 0xffffffbffbdff000 ( 4 KB) [ 0.000000] modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB) [ 0.000000] memory : 0xffffffc000000000 - 0xffffffc040000000 ( 1024 MB) [ 0.000000] .init : 0xffffffc000b25000 - 0xffffffc000b83000 ( 376 KB) [ 0.000000] .text : 0xffffffc000080000 - 0xffffffc000b24564 ( 10898 KB) [ 0.000000] .data : 0xffffffc000b83000 - 0xffffffc000c25fd8 ( 652 KB) [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=8. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 [ 0.000000] NR_IRQS:64 nr_irqs:64 16 [ 0.000000] hisi_clk_register_stub: base=0xffffff8000002af4, comm_base=0xffffff8000008000 [ 0.000000] hisi_clk_init: base ffffff800000a000 [ 0.000000] hisi_clk_init: base ffffff800000c000 [ 0.000000] hisi_clk_init: base ffffff800000e000 [ 0.000000] hisi_clk_init: base ffffff8000010000 [ 0.000000] Architected cp15 timer(s) running at 1.20MHz (phys). [ 0.000005] sched_clock: 56 bits at 1200kHz, resolution 833ns, wraps every 3579139414016ns [ 0.000422] Console: colour dummy device 80x25 [ 0.001558] allocated 4194304 bytes of page_cgroup [ 0.001562] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.001575] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.40 BogoMIPS (lpj=12000) [ 0.001584] pid_max: default: 32768 minimum: 301 [ 0.001694] Security Framework initialized [ 0.001710] SELinux: Initializing. [ 0.001737] SELinux: Starting in permissive mode [ 0.001787] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes) [ 0.001794] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes) [ 0.002309] Initializing cgroup subsys memory [ 0.002333] Initializing cgroup subsys freezer [ 0.002343] Initializing cgroup subsys hugetlb [ 0.002352] Initializing cgroup subsys debug [ 0.004190] /cpus/cpu@0: Missing clock-frequency property [ 0.004230] /cpus/cpu@1: Missing clock-frequency property [ 0.004269] /cpus/cpu@2: Missing clock-frequency property [ 0.004309] /cpus/cpu@3: Missing clock-frequency property [ 0.004350] /cpus/cpu@4: Missing clock-frequency property [ 0.004393] /cpus/cpu@5: Missing clock-frequency property [ 0.004437] /cpus/cpu@6: Missing clock-frequency property [ 0.004481] /cpus/cpu@7: Missing clock-frequency property [ 0.004517] hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 7 counters available [ 0.004545] EFI services will not be available. [ 0.079936] CPU1: Booted secondary processor [ 0.079944] Detected VIPT I-cache on CPU1 [ 0.099879] CPU2: Booted secondary processor [ 0.099882] Detected VIPT I-cache on CPU2 [ 0.119886] CPU3: Booted secondary processor [ 0.119889] Detected VIPT I-cache on CPU3 [ 0.139922] CPU4: Booted secondary processor [ 0.139929] Detected VIPT I-cache on CPU4 [ 0.159920] CPU5: Booted secondary processor [ 0.159924] Detected VIPT I-cache on CPU5 [ 0.179929] CPU6: Booted secondary processor [ 0.179932] Detected VIPT I-cache on CPU6 [ 0.199941] CPU7: Booted secondary processor [ 0.199944] Detected VIPT I-cache on CPU7 [ 0.200014] Brought up 8 CPUs [ 0.200049] SMP: Total of 8 processors activated. [ 0.200626] devtmpfs: initialized [ 0.204994] xor: measuring software checksum speed [ 0.299605] 8regs : 2381.600 MB/sec [ 0.399639] 8regs_prefetch: 2176.000 MB/sec [ 0.499674] 32regs : 2639.200 MB/sec [ 0.599708] 32regs_prefetch: 2321.600 MB/sec [ 0.599714] xor: using function: 32regs (2639.200 MB/sec) <snip>

7 years, 8 months

11
31
0 0

Kernel build issue: hikey-mali branch fails to build...

by Scott Bambrough

I've been going around with Jorge for a couple of days with this. He doesn't see the error but I do using make 4.0. I have spoken with Vishal and he sees this error with make 3.81, and tells me Fathi sees this error in local builds. Is anyone else seeing the following? When I build this branch locally, I get the following error: /media/scottb/linaro/hikey/source/linux/drivers/gpu/arm/utgard/Kbuild:37: *** DMA-BUF is incompatible with non-GPL license. Stop. /media/scottb/linaro/hikey/source/linux/scripts/Makefile.build:416: recipe for target 'drivers/gpu/arm/utgard' failed make[4]: *** [drivers/gpu/arm/utgard] Error 2 /media/scottb/linaro/hikey/source/linux/scripts/Makefile.build:416: recipe for target 'drivers/gpu/arm' failed make[3]: *** [drivers/gpu/arm] Error 2 /media/scottb/linaro/hikey/source/linux/scripts/Makefile.build:416: recipe for target 'drivers/gpu' failed make[2]: *** [drivers/gpu] Error 2 /media/scottb/linaro/hikey/source/linux/Makefile:957: recipe for target 'drivers' failed make[1]: *** [drivers] Error 2 make[1]: Leaving directory '/media/scottb/linaro/kernel/output/kernel-hikey-mali' Makefile:145: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 This error is from: drivers/gpu/arm/utgard/Kbuild The above makefile has the following script in it: # For customer releases the Linux Device Drivers will be provided as ARM proprietary and GPL releases: # The ARM proprietary product will only include the license/proprietary directory # The GPL product will only include the license/gpl directory ifeq ($(wildcard $(src)/linux/license/gpl/*),) ccflags-y += -I$(src)/linux/license/proprietary ifeq ($(CONFIG_MALI400_PROFILING),y) $(error Profiling is incompatible with non-GPL license) endif ifeq ($(CONFIG_PM_RUNTIME),y) $(error Runtime PM is incompatible with non-GPL license) endif ifeq ($(CONFIG_DMA_SHARED_BUFFER),y) $(error DMA-BUF is incompatible with non-GPL license) endif $(error Linux Device integration is incompatible with non-GPL license) else ccflags-y += -I$(src)/linux/license/gpl endif The condition is failing: ifeq ($(wildcard $(src)/linux/license/gpl/*),) $(src) is "drivers/gpu/arm/utgard" drivers/gpu/arm/utgard/linux/license/gpl contains file mali_kernel_license.h wildcard $(src)/linux/license/gpl/* should return "mali_kernel_license.h" but actually returns "" hence the code assumes we are using a proprietary license, and dies because we are using DMA_BUF. Anyone have any thoughts? Since we know we are using GPL code, an easy workaround is to comment out all the code, except for: ccflags-y += -I$(src)/linux/license/gpl Scott -- Scott Bambrough Technical Director, Member Services Linaro

8 years, 1 month

6
18
0 0

enabled NVME in UEFI

by Haojian Zhuang

Hi all, Now NVME feature is enabled in UEFI. The variable could be saved in eMMC, although there's one issue on it. And this feature is merged into UEFI in github of 96boards. You can test it now. If you only create a new variable in UEFI, it works well. If you update the variable with multiple times (more than two), sometimes you'll fail to find the variable after reboot. In this case, we have to reflush the NVME parition in eMMC. Up to now, it's the only one workaround. I'll continue to investigate this issue. When we check the eMMC device, we could find the variable are already flushed into eMMC. Old variables are marked deleted state (0x3d) already. And new variable is marked as added state (0x3f). Best Regards Haojian

8 years, 2 months

1
0
0 0

Re: [Dev] Issue with hikey USB OTG serial adapter

by Leo Yan

hi Tyler, Sorry i missed this mail before. > I have been trying to flash Peter's u-boot port to my early access > hikey board without success. I'm stuck trying to use the burn-boot > tool as the usb-serial device used in download mode keeps > disconnecting. > > [ 165.408788] option 3-3:1.0: device disconnected > [ 251.495189] usb 3-3: new full-speed USB device number 6 using xhci_hcd > [ 251.624288] usb 3-3: New USB device found, idVendor=12d1, idProduct=3609 > [ 251.624292] usb 3-3: New USB device strings: Mfr=1, Product=4, SerialNumber=0 > [ 251.624293] usb 3-3: Product: \xffffffe3\xffffff84\xffffffb0㌲㔴㜶㤸 > [ 251.624295] usb 3-3: Manufacturer: 䕇䕎䥎 > [ 251.624780] option 3-3:1.0: GSM modem (1-port) converter detected > [ 251.624862] usb 3-3: GSM modem (1-port) converter now attached to ttyUSB0 > [ 252.131320] usb 3-3: USB disconnect, device number 6 > [ 252.131539] option1 ttyUSB0: GSM modem (1-port) converter now > disconnected from ttyUSB0 > [ 252.131560] option 3-3:1.0: device disconnected Below are host PC's dump info from my side; from previous experience, the bootROM will firstly enable USB driver for download mode; but it will check timeout (on my board it will take ~78s) if there have no data is transferring on it, it will switch to use the UART to transfer data, so usually we can see the usb will be disconnected. On your board, looks like the interval is very short (less than 1s); i'm curious whether the oscillator has issue so that introduce the timeout value so short. [ 5504.796659] usb 1-1.1: new full-speed USB device number 14 using ehci-pci [ 5504.890448] usb 1-1.1: New USB device found, idVendor=12d1, idProduct=3609 [ 5504.890458] usb 1-1.1: New USB device strings: Mfr=1, Product=4, SerialNumber=0 [ 5504.890463] usb 1-1.1: Product: \xffffffe3\xffffff84\xffffffb0\xffffff84\xffffffb0\xffffffe3\xffffff8c\xffffffb2\xffffff8c\xffffffb2\xffffffe3\xffffff94\xffffffb4\xffffff94\xffffffb4\xffffffe3\xffffff9c\xffffffb6\xffffff9c\xffffffb6\xffffffe3\xffffffa4\xffffffb8\xffffffa4\xffffffb8 [ 5504.890467] usb 1-1.1: Manufacturer: \xffffffe4\xffffff95\xffffff87\xffffff95\xffffff87\xffffffe4\xffffff95\xffffff8e\xffffff95\xffffff8e\xffffffe4\xffffffa5\xffffff8e\xffffffa5\xffffff8e [ 5504.891140] option 1-1.1:1.0: GSM modem (1-port) converter detected [ 5504.891373] usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB0 [ 5582.211632] usb 1-1.1: USB disconnect, device number 14 [ 5582.212224] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 [ 5582.212254] option 1-1.1:1.0: device disconnected Here have two methods u can try: Method 1: Before you power on the board, could u firstly hotplug USB cable firstly and check if this can be helpful? Method 2: Have u enabled the serial out on your board? https://lists.96boards.org/pipermail/dev/2015-March/000159.html If so, then when you open minicom, u can see the log like below; then that means can download binaries with UART, so after the string "Switch to UART download..." has been printed out, u can use burn-boot tool to download image with the UART port (suppose it will be ttyUSB0 or ttyUSB1); USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package usb data recieving 60s time out.... Switch to UART download... Thanks, Leo Yan

8 years, 2 months

1
0
0 0

Re: [Dev] loop xinliang etc.//答复: X fails to load on current alip image....

by Lars-Peter Clausen

On 03/30/2015 05:00 AM, George Grey wrote: > Hi > Thank you - that will be very helpful > >> But, the import fact is that: >> Recent days i and our SoC guys are analyzing the HDMI signal issue. We >> have tested many mode timings on TV monitors and PC monitors and we found >> very a few mode timings can work, including the 720P. SoC guys said that >> TV monitors are follow the CEA 681 standard and our SoC can't math this >> standard and during our SoC design phase HDMI is not taken into account. >> I'm afraid this signal can't be fixed and our SoC can't support HDMI well. > > Can you explain the problem and the limitations of the SoC in technical > detail? > You say that a few timings do work including 720p. Can you explain the > technical reason for this? > Is it possible to determine which timing/configurations will work and > which will not? > It's not 720p that's working, at least not the CEA compliant 720p. It's a timings setting where the active resolution is the same as 720p, but the front porch/back porch/blanking timings as well as the refresh rate are different. The reason why this timing works is because the result of the formula that I explained in the earlier mail ("lengthA * clkB / clkA = lengthB") is integer for these settings. And if the result is integer the video timings are uniform in the DSI/HDMI clock domain and hence the monitor will be able to recognize the timings and display the image. For the timing we are talking about the LDI clock is 72 MHz, the DSI clock is 297.6 Mhz, the total line length in the LDI clock domain is 1650. The HDMI clock is DSI clock / 4. If you insert that into the above formula you get 1650 * (297.6 / 4) / 72.0 = 1705.0. That's why it works. But it's not 720p and not what the monitor says it supports, but most modern monitors are quite forgiving when it comes to timing as long as the active area is correct and the refresh rate is within reasonable bounds. But you'll not pass compliance testing with this. - Lars -- -- Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer: William A. Martin, Margaret Seif

8 years, 2 months

3
2
0 0

WiFi 802.11g access point woes

by Paul Sokolovsky

Hello, As was noted in recent messages on the list, recent Debian builds (e.g. #118, #124) has WiFi working. However, I had troubles connecting to my Internet access point, with wpa_supplicant (or kernel while running it) throwing timeout errors waiting for AP authentication response. After fiddling with it, I remembered that the AP is 802.11g, grabbed a 802.11n mobile router, and the HiKey connected to it without issues. I tried to play with few seemingly related wpa_supplication config params, but nothing had an effect (btw, it's a bit of chore, because on stop, wpa_supplicant brings wlan0 down, and it's broken after that, not up'able again; "reboot" doesn't work, and there's no hardware reset button, so disconnecting power jack is the only choice). So, I figure the problem is in driver. I'm currently reading TI's docs on WL1835MOD (http://processors.wiki.ti.com/index.php/WL18xx) to see if there's anything related, but if someone may have any hints, that would be appreciated. Thanks, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

8 years, 2 months

3
4
0 0

Re: [Dev] loop xinliang etc.//答复: X fails to load on current alip image....

by xinliang

Loop yinshengbao and xieqian, On Monday, March 30, 2015 11:00 AM, George Grey wrote: > >> On Mar 29, 2015, at 9:50 PM, xinliang <xin3liang(a)qq.com >> <mailto:xin3liang@qq.com>> wrote: >> >> >> >> On Saturday, March 28, 2015 09:25 PM, George Grey wrote: >>> >>>> On Mar 28, 2015, at 5:55 AM, xinliang <xin3liang(a)qq.com >>>> <mailto:xin3liang@qq.com>> wrote: >>>> >>>> Hi Scott, >>>> Sorry for late replying. I just come back from a travel. >>>> >>>> >>>> On Friday, March 27, 2015 03:58 PM, Dan zhao wrote: >>>>> >>>>>> -----邮件原件----- >>>>>> 发件人: Scott Bambrough [mailto:scott.bambrough@linaro.org] >>>>>> 发送时间: 2015年3月27日 7:07 >>>>>> 收件人: Benjamin Gaignard; dev(a)lists.96boards.org >>>>>> <mailto:dev@lists.96boards.org> >>>>>> 抄送: Tom Gall; Guodong Xu; Lars-Peter Clausen; George Grey; Dan zhao >>>>>> 主题: Re: [Dev] X fails to load on current alip image.... >>>>>> >>>>>> On Thu, Mar 26, 2015 at 3:03 PM, Benjamin Gaignard >>>>>> <benjamin.gaignard(a)linaro.org >>>>>> <mailto:benjamin.gaignard@linaro.org>> wrote: >>>>>>> It could be simple call to an i2c adapter. >>>>>>> For example it is done like this in sti drm/kms driver: >>>>>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/ >>>>>>> drivers/gpu/drm/sti/sti_hdmi.c?id=refs/tags/next-20150326#n695 >>>>>>> >>>>>>> Benjamin >>>>>>> >>>>>>> Le jeudi 26 mars 2015, Scott Bambrough >>>>>>> <scott.bambrough(a)linaro.org> a >>>>>>> écrit >>>>>>> : >>>>>>> >>>>>>>> We have no hdmi ddc client in the kernel. I suspect this is the >>>>>>>> patches that HiSilicon needs to give us Guodong. >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> On Thu, Mar 26, 2015 at 1:58 PM, Tom Gall <tgall(a)gentoo.org> wrote: >>>>>>>>> FYI >>>>>>>>> >>>>>>>>> Advise from Benjamin. >>>>>>>>> >>>>>>>>> Begin forwarded message: >>>>>>>>> >>>>>>>>> Date: March 26, 2015 at 8:57:34 AM PDT >>>>>>>>> Subject: Re: [Dev] X fails to load on current alip image.... >>>>>>>>> From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> >>>>>>>>> To: Tom Gall <tgall(a)gentoo.org> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> not sound familiar but I think that the hdmi ddc client isn't set >>>>>>>>> on the correct i2c bus so EDID can't be retrieved. >>>>>>>>> >>>>>>>>> I suggest to check if the hdmi ddc is set on the correct i2c bus >>>>>>>>> and if the dispaly is well connected. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Benjamin >>>>>>>>> >>>>>>>>> 2015-03-26 16:12 GMT+01:00 Tom Gall <tgall(a)gentoo.org>: >>>>>>>>> >>>>>>>>> Hi Benjamin, >>>>>>>>> >>>>>>>>> Does the drm error below look familiar? >>>>>>>>> >>>>>>>>> [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >>>>>>>>> encoder i2c client >>>>>>>>> >>>>>>>>> Is that a real error or is there something else to look at? >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Tom >>>>>>>>> >>>>>>>>> Begin forwarded message: >>>>>>>>> >>>>>>>>> From: Scott Bambrough <scott.bambrough(a)linaro.org> >>>>>>>>> Subject: [Dev] X fails to load on current alip image.... >>>>>>>>> To: <dev(a)lists.96boards.org> >>>>>>>>> Date: March 26, 2015 at 7:21:51 AM PDT >>>>>>>>> >>>>>>>>> I had a look at this failure, debugged this a bit... >>>>>>>>> >>>>>>>>> Started with latest snapshot (135), X fails to load. >>>>>>>>> >>>>>>>>> Rebuild kernel with the latest git, hikey-mali branch Rebuild boot >>>>>>>>> and system images using latest kernel, setup networking via >>>>>>>>> eth0 by >>>>>>>>> default so I can ssh in. >>>>>>>>> Flash boot and system partitions using rebuilt images. >>>>>>>>> Reboot (1) >>>>>>>>> >>>>>>>>> Looking into Xorg.0.log see the following error: >>>>>>>>> >>>>>>>>> [ 60.310] (==) RandR enabled >>>>>>>>> [ 60.333] (II) SELinux: Disabled on system >>>>>>>>> [ 60.336] (II) AIGLX: Screen 0 is not DRI2 capable >>>>>>>>> [ 60.336] (EE) AIGLX: reverting to software rendering >>>>>>>>> [ 60.336] (EE) AIGLX error: dlopen of >>>>>>>>> /usr/lib/aarch64-linux-gnu/dri/swrast_dri.so failed >>>>>>>>> (/usr/lib/aarch64-linux-gnu/dri/swrast_dri.so: cannot open shared >>>>>>>>> object file: No such file or directory) >>>>>>>>> [ 60.336] (EE) GLX: could not load software renderer >>>>>>>>> [ 60.336] (II) GLX: no usable GL providers found for screen 0 >>>>>>>>> [ 60.426] (II) config/udev: Adding drm device (/dev/dri/card0) >>>>>>>>> [ 60.426] (II) xfree86: Adding drm device (/dev/dri/card0) >>>>>>>>> [ 60.429] (EE) /dev/dri/card0: failed to set DRM interface >>>>>>>>> version >>>>>>>>> 1.4: Invalid argument >>>>>>>>> [ 60.590] (EE) Server terminated successfully (0). Closing >>>>>>>>> log file. >>>>>>>>> >>>>>>>>> Solve that error by installing the following package: >>>>>>>>> # apt-get install libgl1-mesa-dri >>>>>>>>> >>>>>>>>> Reboot (2) >>>>>>>>> Missing shared library is found. >>>>>>>>> >>>>>>>>> [ 43.500] (==) RandR enabled >>>>>>>>> [ 43.523] (II) SELinux: Disabled on system >>>>>>>>> [ 43.526] (II) AIGLX: Screen 0 is not DRI2 capable >>>>>>>>> [ 43.526] (EE) AIGLX: reverting to software rendering >>>>>>>>> [ 44.621] (II) AIGLX: Loaded and initialized swrast >>>>>>>>> [ 44.621] (II) GLX: Initialized DRISWRAST GL provider for >>>>>>>>> screen 0 >>>>>>>>> [ 44.970] (II) config/udev: Adding drm device (/dev/dri/card0) >>>>>>>>> [ 44.971] (II) xfree86: Adding drm device (/dev/dri/card0) >>>>>>>>> [ 44.973] (EE) /dev/dri/card0: failed to set DRM interface >>>>>>>>> version >>>>>>>>> 1.4: Invalid argument >>>>>>>>> >>>>>>>>> Why the error "/dev/dri/card0: failed to set DRM interface version >>>>>>>>> 1.4: Invalid argument"? >>>>>>>>> dmesg output has the following error >>>>>>>>> >>>>>>>>> [ 44.985050] ------------[ cut here ]------------ >>>>>>>>> [ 44.985082] WARNING: CPU: 1 PID: 1453 at >>>>>>>>> /media/scottb/linaro/hikey/source/linux/drivers/gpu/drm/drm_ioctl.c >>>>>>>>> :143 >>>>>>>>> drm_setversion+0x168/0x16c() >>>>>>>>> [ 44.985095] No drm_driver.set_busid() implementation >>>>>>>>> provided by >>>>>>>>> hisi_drm_driver. Use drm_dev_set_unique() to set the unique name >>>>>>>>> explicitly. >>>>>>>>> [ 44.985100] Modules linked in: >>>>>>>>> [ 44.985106] btwilink bluetooth st_drv mali wl18xx wlcore >>>>>>>>> mac80211 >>>>>>>>> cfg80211 rfkill wlcore_sdio >>>>>>>>> [ 44.985136] CPU: 1 PID: 1453 Comm: Xorg Tainted: G W >>>>>>>>> 3.18.0linaro-hikey+ #3 >>>>>>>>> [ 44.985141] Call trace: >>>>>>>>> [ 44.987598] [<ffffffc000088538>] dump_backtrace+0x0/0x124 >>>>>>>>> [ 44.987606] [<ffffffc00008866c>] show_stack+0x10/0x1c >>>>>>>>> [ 44.987616] [<ffffffc000806bfc>] dump_stack+0x74/0xb8 >>>>>>>>> [ 44.987625] [<ffffffc0000afdb4>] warn_slowpath_common+0x90/0xb8 >>>>>>>>> [ 44.987631] [<ffffffc0000afe28>] warn_slowpath_fmt+0x4c/0x58 >>>>>>>>> [ 44.987639] [<ffffffc0004eaec4>] drm_setversion+0x164/0x16c >>>>>>>>> [ 44.987646] [<ffffffc0004eaaa0>] drm_ioctl+0x254/0x4d0 >>>>>>>>> [ 44.987656] [<ffffffc0001d216c>] do_vfs_ioctl+0x368/0x5b0 >>>>>>>>> [ 44.987663] [<ffffffc0001d2434>] SyS_ioctl+0x80/0x98 >>>>>>>>> [ 44.987669] ---[ end trace bf426acc001551e5 ]--- >>>>>>>>> >>>>>>>>> Solve that error by applying the following patch: >>>>>>>>> >>>>>>>>> diff --git a/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >>>>>>>>> b/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >>>>>>>>> index 987c530..b646bab 100644 >>>>>>>>> --- a/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >>>>>>>>> +++ b/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >>>>>>>>> @@ -147,6 +147,7 @@ static struct drm_driver hisi_drm_driver = { >>>>>>>>> | DRIVER_PRIME, >>>>>>>>> .load = hisi_drm_load, >>>>>>>>> .unload = hisi_drm_unload, >>>>>>>>> + .set_busid = drm_platform_set_busid, >>>>>>>>> .fops = &hisi_drm_fops, >>>>>>>>> .name = "hisi-drm", >>>>>>>>> .desc = "Hisilicon Terminal SoCs DRM Driver", >>>>>>>>> >>>>>>>>> Rebuild kernel >>>>>>>>> Rebuild boot partition image with latest kernel and flash to the >>>>>>>>> boot partition of the HiKey Reboot (3) >>>>>>>>> >>>>>>>>> dmesg has the following messages from DRM: >>>>>>>>> >>>>>>>>> linaro@linaro-alip:~/sdcard/xwork/3$ grep drm dmesg.txt >>>>>>>>> [ 2.410636] calling drm_core_init+0x0/0x12c @ 1 >>>>>>>>> [ 2.410705] [drm] Initialized drm 1.1.0 20060810 >>>>>>>>> [ 2.410720] initcall drm_core_init+0x0/0x12c returned 0 >>>>>>>>> after 69 >>>>>>>>> usecs >>>>>>>>> [ 2.410742] calling hisi_drm_platform_driver_init+0x0/0x20 @ 1 >>>>>>>>> [ 2.411790] [drm] Initialized hisi-drm 1.0.0 20141224 on >>>>>>>>> minor 0 >>>>>>>>> [ 2.411893] initcall hisi_drm_platform_driver_init+0x0/0x20 >>>>>>>>> returned 0 after 1108 usecs >>>>>>>>> [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >>>>>>>>> encoder i2c client >>>>>>>>> [ 3.546316] [drm] HDMI: new_status=1,old_status=2,hpd=1,dpms=3 >>>>>>>>> [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block 0 >>>>>>>>> invalid. >>>>>>>>> [ 3.602469] [drm] HDMI: mode=0,format_422=0,format_ycbcr=0 >>>>>>>>> [ 3.603762] [drm] May has one empty edid block! >>>>>>>>> [ 3.624268] [drm] >>>>>>>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>>>>>>> [ 3.624270] [drm] mipi_init , exit success! >>>>>>>>> [ 3.654185] hisi-drm smb:display-subsystem: fb0: frame buffer >>>>>> device >>>>>>>>> [ 3.654192] hisi-drm smb:display-subsystem: registered >>>>>>>>> panic notifier >>>>>>>>> [ 43.134240] [drm] phystopstateclklane is not ready. >>>>>>>>> [ 43.134350] [drm] >>>>>>>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>>>>>>> [ 43.134350] [drm] mipi_init , exit success! >>>>>>>>> >>>>>>>>> Xorg.0.log error setting DRM version is gone. >>>>>>>>> >>>>>>>>> [ 43.134] (==) RandR enabled >>>>>>>>> [ 43.158] (II) SELinux: Disabled on system >>>>>>>>> [ 43.161] (II) AIGLX: Screen 0 is not DRI2 capable >>>>>>>>> [ 43.161] (EE) AIGLX: reverting to software rendering >>>>>>>>> [ 43.173] (II) AIGLX: Loaded and initialized swrast >>>>>>>>> [ 43.173] (II) GLX: Initialized DRISWRAST GL provider for >>>>>>>>> screen 0 >>>>>>>>> >>>>>>>>> Why do these errors occur? >>>>>>>>> [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >>>>>>>>> encoder i2c client >>>> This is not a problem, the dsi module is waiting for HDMI module. >>>> When dsi module can't find HDMI slave encoder module it will return >>>> -EPROBE_DEFER to deffer probe. >>>> After the HDMI module has been initialized. This error msg would >>>> not come again. >>>>>>>>> [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block 0 >>>>>>>>> invalid. >>>> EDID error doesn't matter now. Due to the unfixed signal issue, now >>>> we explicitly set the 720P timing parameters. So the timing >>>> parameters doesn't come from EDID. >>> >>> Hello - this is in fact a major problem for us. We want to make the >>> HDMI work “properly” with all monitors. We also need to investigate >>> the possible SoC clock timing issue identified by Lars at Analog >>> Devices. Therefore we want to enable the EDID data so that we can >>> then test different display timings and configurations. >>> To do testing, characterization and validation of different monitor >>> timings we also need a command line tool for debugging to enable us >>> to change the DSI timings and clock set ups on the SoC (see Lars >>> emails) for different displays. Here is the use case: >>> >>> 1. Read EDID information on boot >>> 2. Boot up in known working 720p configuration (this is what happens >>> today) >>> 3. User reads the EDID data using dmesg >>> 4. Users logs in from remote PC using ssh >>> 5. Using the EDID information and a debug tool which can adjust >>> clock settings and DSI output configuration the user sets the >>> monitor timings for different supported frequency, no of pixels, >>> lines etc. The debug tool makes the appropriate changes in the SoC >>> and the ADV7533. >>> 6. User records whether the monitor is working correctly >>> 7. If the monitor fails the user can go back to the known working >>> 720p setup using the debug tool. >>> >>> This will help us to characterize which timing setups work and which >>> fail so that we can find the root cause of HDMI not working at >>> different frequencies/configurations. >>> Can you help on this? >> Yes, I can read EDID properly with my local patch, i'll push this >> patch to 96boards' Github kernel as soon as possible. >> Such a debug tool is something like the "modetest" tool in libdrm. >> I'll try it. > > Hi > Thank you - that will be very helpful > >> But, the import fact is that: >> Recent days i and our SoC guys are analyzing the HDMI signal issue. >> We have tested many mode timings on TV monitors and PC monitors and >> we found very a few mode timings can work, including the 720P. SoC >> guys said that TV monitors are follow the CEA 681 standard and our >> SoC can't math this standard and during our SoC design phase HDMI is >> not taken into account. >> I'm afraid this signal can't be fixed and our SoC can't support HDMI >> well. > > Can you explain the problem and the limitations of the SoC in > technical detail? > You say that a few timings do work including 720p. Can you explain the > technical reason for this? > Is it possible to determine which timing/configurations will work and > which will not? > Hi yinshengbao and xieqian, could you two help to explain this? Thanks. Best regards, Xinliang > Thank you for all your help on this. > > Kind regards > George > >>> >>>>>>>>> [ 43.134240] [drm] phystopstateclklane is not ready. >>>>>>>>> >>>>>>>>> Out of my depth here, punting to HiSilicon engineers. >>>>>>>>> Guodong can >>>>>>>>> you take up these errors with HiSilicon please. >>>>>>>>> >>>>>>>>> Attached logs (dmesg, Xorg.0.log) from after every reboot. In >>>>>>>>> text >>>>>>>>> above you will see: >>>>>>>>> Reboot (x) -- logs are in directory x if the tarball >>>>>>>>> >>>>>>>>> Also attached script (build.sh) I use to rebuild the images for >>>>>>>>> flashing. It will need some rework as it is pretty custom to my >>>>>>>>> system. >>>>>>>>> >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Scott Bambrough >>>>>>>>> Technical Director, Member Services Linaro >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Benjamin Gaignard >>>>>>>>> >>>>>>>>> Graphic Working Group >>>>>>>>> >>>>>>>>> Linaro.org <http://linaro.org/> │ Open source software for ARM >>>>>>>>> SoCs >>>>>>>>> >>>>>>>>> Follow Linaro: Facebook | Twitter | Blog >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Scott Bambrough >>>>>>>> Technical Director, Member Services >>>>>>>> Linaro >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Benjamin Gaignard >>>>>>> >>>>>>> Graphic Working Group >>>>>>> >>>>>>> Linaro.org <http://linaro.org/> │ Open source software for ARM SoCs >>>>>>> >>>>>>> Follow Linaro: Facebook | Twitter | Blog >>>>>>> >>>>>>> >>>>>> Yeah, I realized that afterwards. Seems like the Analog Device code >>>>>> in drivers/gpu/drm/i2c/adv7533.c drivers/media/i2c/adv7533.c >>>>>> registers >>>>>> one. >>>>>> >>>>>> See: static int adv7533_probe(struct i2c_client *i2c, const struct >>>>>> i2c_device_id *id) >>>>>> adv7533->i2c_main = i2c; >>>>>> adv7533->i2c_edid = i2c_new_dummy(i2c->adapter, >>>>>> edid_i2c_addr >> >>>>>> 1); >>>>>> if (!adv7533->i2c_edid) >>>>>> return -ENOMEM; >>>>>> >>>>>> If I grep through the dmesg output: >>>>>> >>>>>> scottb@eagle:~/tmp/logs/3$ grep "adv7533\|drm" dmesg.txt >>>>>> [ 2.410636] calling drm_core_init+0x0/0x12c @ 1 >>>>>> [ 2.410705] [drm] Initialized drm 1.1.0 20060810 >>>>>> [ 2.410720] initcall drm_core_init+0x0/0x12c returned 0 after >>>>>> 69 usecs >>>>>> [ 2.410742] calling hisi_drm_platform_driver_init+0x0/0x20 @ 1 >>>>>> [ 2.411790] [drm] Initialized hisi-drm 1.0.0 20141224 on minor 0 >>>>>> [ 2.411893] initcall hisi_drm_platform_driver_init+0x0/0x20 >>>>>> returned 0 after 1108 usecs >>>>>> [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >>>>>> encoder i2c client >>>>>> [ 2.420194] calling adv7533_init+0x0/0x24 @ 1 >>>>>> [ 2.420254] initcall adv7533_init+0x0/0x24 returned 0 after 44 >>>>>> usecs >>>>>> [ 3.546316] [drm] HDMI: new_status=1,old_status=2,hpd=1,dpms=3 >>>>>> [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block >>>>>> 0 invalid. >>>>>> [ 3.602469] [drm] HDMI: mode=0,format_422=0,format_ycbcr=0 >>>>>> [ 3.603762] [drm] May has one empty edid block! >>>>>> [ 3.624268] [drm] >>>>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>>>> [ 3.624270] [drm] mipi_init , exit success! >>>>>> [ 3.654185] hisi-drm smb:display-subsystem: fb0: frame buffer >>>>>> device >>>>>> [ 3.654192] hisi-drm smb:display-subsystem: registered panic >>>>>> notifier >>>>>> [ 43.134240] [drm] phystopstateclklane is not ready. >>>>>> [ 43.134350] [drm] >>>>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>>>> [ 43.134350] [drm] mipi_init , exit success! >>>>>> >>>>>> It appears the HiSilicon DRM driver is initialized, then the ADV7533. >>>>>> Could it just be the init order is wrong? >>>>>> >>>>>> [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >>>>>> encoder i2c client >>>>>> The above error occurs before the ADV7533 driver is initialized. >>>>>> >>>>>> [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block >>>>>> 0 invalid. >>>>>> [ 3.602469] [drm] HDMI: mode=0,format_422=0,format_ycbcr=0 >>>>>> [ 3.603762] [drm] May has one empty edid block! >>>>>> >>>>>> The above errors stem from a call to: >>>>>> static int adv7533_get_modes(struct drm_encoder *encoder, struct >>>>>> drm_connector *connector) >>>>>> >>>>>> [ 3.654185] hisi-drm smb:display-subsystem: fb0: frame buffer >>>>>> device >>>>>> [ 3.654192] hisi-drm smb:display-subsystem: registered panic >>>>>> notifier >>>>>> >>>>>> These indicate the framebuffer is being created. These stem from >>>>>> a call to: >>>>>> static int drm_fb_helper_single_fb_probe(struct drm_fb_helper >>>>>> *fb_helper, int preferred_bpp) >>>>>> >>>>>> which is called from: >>>>>> bool drm_fb_helper_initial_config(struct drm_fb_helper >>>>>> *fb_helper, int >>>>>> bpp_sel) >>>>>> >>>>>> which is called from: >>>>>> static struct hisi_drm_fbdev *hisi_drm_fbdev_create(struct >>>>>> drm_device *dev, >>>>>> unsigned int preferred_bpp, unsigned int num_crtc, >>>>>> unsigned int max_conn_count) >>>>>> >>>>>> Another thing I found odd is mipi_init seems to be called twice: >>>>>> Why? >>>>>> >>>>>> [ 3.624268] [drm] >>>>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>>>> [ 3.624270] [drm] mipi_init , exit success! >>>>>> >>>>>> [ 43.134350] [drm] >>>>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>>>> [ 43.134350] [drm] mipi_init , exit success! >>>>>> >>>>>> mipi_init is called from: >>>>>> static int hisi_dsi_init(struct hisi_dsi *dsi) >>>>>> >>>>>> which is called from: >>>>>> static int hisi_dsi_enable(struct hisi_dsi *dsi) >>>>>> >>>>>> which is called from: >>>>>> static void hisi_drm_encoder_dpms(struct drm_encoder *encoder, >>>>>> int mode) >>>>>> when mode = DRM_MODE_DPMS_ON >>>>>> >>>>>> There is a corresponding >>>>>> static int hisi_dsi_disable(struct hisi_dsi *dsi) >>>>>> called when mode is one of DRM_MODE_DPMS_STANDBY, >>>>>> DRM_MODE_DPMS_SUSPEND, DRM_MODE_DPMS_OFF >>>>>> >>>>>> It does nothing however: >>>>>> >>>>>> static int hisi_dsi_disable(struct hisi_dsi *dsi) >>>>>> { >>>>>> DRM_DEBUG_DRIVER("enter.\n"); >>>>>> DRM_DEBUG_DRIVER("exit success.\n"); >>>>>> return 0; >>>>>> } >>>>>> >>>>>> [ 43.134240] [drm] phystopstateclklane is not ready. >>>>>> This error is from mipi_init. The first time through mipi_init it >>>>>> doesn't occur, it does on the second time though. >>>>>> Seems to indicate a problem with the clocks for the mipi dsi data >>>>>> lanes. >>>>>> >>>>>> I really think we need to sort this out. >>>>>> >>>>>> Scott >>>>>> >>>>>> -- >>>>>> Scott Bambrough >>>>>> Technical Director, Member Services >>>>>> Linaro >>>> Anyway, I'll take a look at the latest debian img to see if the >>>> "fail to load " problem has someting about the drm driver changes >>>> during recent period. >>> >>> Thanks very much - the failure happened when the HDMI code was >>> changed to the DRM driver. If this can be fixed we can again bring >>> up the GUI and test Mali GPU acceleration. >>> >>> Kind regards >>> George >>> >>>> Best regards, >>>> -Xinliang Liu >>> >> >

8 years, 2 months

1
0
0 0

Re: [Dev] loop xinliang etc.//答复: X fails to load on current alip image....

by xinliang

On Saturday, March 28, 2015 09:25 PM, George Grey wrote: > >> On Mar 28, 2015, at 5:55 AM, xinliang <xin3liang(a)qq.com >> <mailto:xin3liang@qq.com>> wrote: >> >> Hi Scott, >> Sorry for late replying. I just come back from a travel. >> >> >> On Friday, March 27, 2015 03:58 PM, Dan zhao wrote: >>> >>>> -----邮件原件----- >>>> 发件人: Scott Bambrough [mailto:scott.bambrough@linaro.org] >>>> 发送时间: 2015年3月27日 7:07 >>>> 收件人: Benjamin Gaignard; dev(a)lists.96boards.org >>>> <mailto:dev@lists.96boards.org> >>>> 抄送: Tom Gall; Guodong Xu; Lars-Peter Clausen; George Grey; Dan zhao >>>> 主题: Re: [Dev] X fails to load on current alip image.... >>>> >>>> On Thu, Mar 26, 2015 at 3:03 PM, Benjamin Gaignard >>>> <benjamin.gaignard(a)linaro.org >>>> <mailto:benjamin.gaignard@linaro.org>> wrote: >>>>> It could be simple call to an i2c adapter. >>>>> For example it is done like this in sti drm/kms driver: >>>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/ >>>>> drivers/gpu/drm/sti/sti_hdmi.c?id=refs/tags/next-20150326#n695 >>>>> >>>>> Benjamin >>>>> >>>>> Le jeudi 26 mars 2015, Scott Bambrough <scott.bambrough(a)linaro.org> a >>>>> écrit >>>>> : >>>>> >>>>>> We have no hdmi ddc client in the kernel. I suspect this is the >>>>>> patches that HiSilicon needs to give us Guodong. >>>>>> >>>>>> Scott >>>>>> >>>>>> On Thu, Mar 26, 2015 at 1:58 PM, Tom Gall <tgall(a)gentoo.org> wrote: >>>>>>> FYI >>>>>>> >>>>>>> Advise from Benjamin. >>>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>> Date: March 26, 2015 at 8:57:34 AM PDT >>>>>>> Subject: Re: [Dev] X fails to load on current alip image.... >>>>>>> From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> >>>>>>> To: Tom Gall <tgall(a)gentoo.org> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> not sound familiar but I think that the hdmi ddc client isn't set >>>>>>> on the correct i2c bus so EDID can't be retrieved. >>>>>>> >>>>>>> I suggest to check if the hdmi ddc is set on the correct i2c bus >>>>>>> and if the dispaly is well connected. >>>>>>> >>>>>>> Regards, >>>>>>> Benjamin >>>>>>> >>>>>>> 2015-03-26 16:12 GMT+01:00 Tom Gall <tgall(a)gentoo.org>: >>>>>>> >>>>>>> Hi Benjamin, >>>>>>> >>>>>>> Does the drm error below look familiar? >>>>>>> >>>>>>> [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >>>>>>> encoder i2c client >>>>>>> >>>>>>> Is that a real error or is there something else to look at? >>>>>>> >>>>>>> Thanks! >>>>>>> Tom >>>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>> From: Scott Bambrough <scott.bambrough(a)linaro.org> >>>>>>> Subject: [Dev] X fails to load on current alip image.... >>>>>>> To: <dev(a)lists.96boards.org> >>>>>>> Date: March 26, 2015 at 7:21:51 AM PDT >>>>>>> >>>>>>> I had a look at this failure, debugged this a bit... >>>>>>> >>>>>>> Started with latest snapshot (135), X fails to load. >>>>>>> >>>>>>> Rebuild kernel with the latest git, hikey-mali branch Rebuild boot >>>>>>> and system images using latest kernel, setup networking via eth0 by >>>>>>> default so I can ssh in. >>>>>>> Flash boot and system partitions using rebuilt images. >>>>>>> Reboot (1) >>>>>>> >>>>>>> Looking into Xorg.0.log see the following error: >>>>>>> >>>>>>> [ 60.310] (==) RandR enabled >>>>>>> [ 60.333] (II) SELinux: Disabled on system >>>>>>> [ 60.336] (II) AIGLX: Screen 0 is not DRI2 capable >>>>>>> [ 60.336] (EE) AIGLX: reverting to software rendering >>>>>>> [ 60.336] (EE) AIGLX error: dlopen of >>>>>>> /usr/lib/aarch64-linux-gnu/dri/swrast_dri.so failed >>>>>>> (/usr/lib/aarch64-linux-gnu/dri/swrast_dri.so: cannot open shared >>>>>>> object file: No such file or directory) >>>>>>> [ 60.336] (EE) GLX: could not load software renderer >>>>>>> [ 60.336] (II) GLX: no usable GL providers found for screen 0 >>>>>>> [ 60.426] (II) config/udev: Adding drm device (/dev/dri/card0) >>>>>>> [ 60.426] (II) xfree86: Adding drm device (/dev/dri/card0) >>>>>>> [ 60.429] (EE) /dev/dri/card0: failed to set DRM interface >>>>>>> version >>>>>>> 1.4: Invalid argument >>>>>>> [ 60.590] (EE) Server terminated successfully (0). Closing >>>>>>> log file. >>>>>>> >>>>>>> Solve that error by installing the following package: >>>>>>> # apt-get install libgl1-mesa-dri >>>>>>> >>>>>>> Reboot (2) >>>>>>> Missing shared library is found. >>>>>>> >>>>>>> [ 43.500] (==) RandR enabled >>>>>>> [ 43.523] (II) SELinux: Disabled on system >>>>>>> [ 43.526] (II) AIGLX: Screen 0 is not DRI2 capable >>>>>>> [ 43.526] (EE) AIGLX: reverting to software rendering >>>>>>> [ 44.621] (II) AIGLX: Loaded and initialized swrast >>>>>>> [ 44.621] (II) GLX: Initialized DRISWRAST GL provider for >>>>>>> screen 0 >>>>>>> [ 44.970] (II) config/udev: Adding drm device (/dev/dri/card0) >>>>>>> [ 44.971] (II) xfree86: Adding drm device (/dev/dri/card0) >>>>>>> [ 44.973] (EE) /dev/dri/card0: failed to set DRM interface >>>>>>> version >>>>>>> 1.4: Invalid argument >>>>>>> >>>>>>> Why the error "/dev/dri/card0: failed to set DRM interface version >>>>>>> 1.4: Invalid argument"? >>>>>>> dmesg output has the following error >>>>>>> >>>>>>> [ 44.985050] ------------[ cut here ]------------ >>>>>>> [ 44.985082] WARNING: CPU: 1 PID: 1453 at >>>>>>> /media/scottb/linaro/hikey/source/linux/drivers/gpu/drm/drm_ioctl.c >>>>>>> :143 >>>>>>> drm_setversion+0x168/0x16c() >>>>>>> [ 44.985095] No drm_driver.set_busid() implementation provided by >>>>>>> hisi_drm_driver. Use drm_dev_set_unique() to set the unique name >>>>>>> explicitly. >>>>>>> [ 44.985100] Modules linked in: >>>>>>> [ 44.985106] btwilink bluetooth st_drv mali wl18xx wlcore >>>>>>> mac80211 >>>>>>> cfg80211 rfkill wlcore_sdio >>>>>>> [ 44.985136] CPU: 1 PID: 1453 Comm: Xorg Tainted: G W >>>>>>> 3.18.0linaro-hikey+ #3 >>>>>>> [ 44.985141] Call trace: >>>>>>> [ 44.987598] [<ffffffc000088538>] dump_backtrace+0x0/0x124 >>>>>>> [ 44.987606] [<ffffffc00008866c>] show_stack+0x10/0x1c >>>>>>> [ 44.987616] [<ffffffc000806bfc>] dump_stack+0x74/0xb8 >>>>>>> [ 44.987625] [<ffffffc0000afdb4>] warn_slowpath_common+0x90/0xb8 >>>>>>> [ 44.987631] [<ffffffc0000afe28>] warn_slowpath_fmt+0x4c/0x58 >>>>>>> [ 44.987639] [<ffffffc0004eaec4>] drm_setversion+0x164/0x16c >>>>>>> [ 44.987646] [<ffffffc0004eaaa0>] drm_ioctl+0x254/0x4d0 >>>>>>> [ 44.987656] [<ffffffc0001d216c>] do_vfs_ioctl+0x368/0x5b0 >>>>>>> [ 44.987663] [<ffffffc0001d2434>] SyS_ioctl+0x80/0x98 >>>>>>> [ 44.987669] ---[ end trace bf426acc001551e5 ]--- >>>>>>> >>>>>>> Solve that error by applying the following patch: >>>>>>> >>>>>>> diff --git a/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >>>>>>> b/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >>>>>>> index 987c530..b646bab 100644 >>>>>>> --- a/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >>>>>>> +++ b/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >>>>>>> @@ -147,6 +147,7 @@ static struct drm_driver hisi_drm_driver = { >>>>>>> | DRIVER_PRIME, >>>>>>> .load = hisi_drm_load, >>>>>>> .unload = hisi_drm_unload, >>>>>>> + .set_busid = drm_platform_set_busid, >>>>>>> .fops = &hisi_drm_fops, >>>>>>> .name = "hisi-drm", >>>>>>> .desc = "Hisilicon Terminal SoCs DRM Driver", >>>>>>> >>>>>>> Rebuild kernel >>>>>>> Rebuild boot partition image with latest kernel and flash to the >>>>>>> boot partition of the HiKey Reboot (3) >>>>>>> >>>>>>> dmesg has the following messages from DRM: >>>>>>> >>>>>>> linaro@linaro-alip:~/sdcard/xwork/3$ grep drm dmesg.txt >>>>>>> [ 2.410636] calling drm_core_init+0x0/0x12c @ 1 >>>>>>> [ 2.410705] [drm] Initialized drm 1.1.0 20060810 >>>>>>> [ 2.410720] initcall drm_core_init+0x0/0x12c returned 0 after 69 >>>>>>> usecs >>>>>>> [ 2.410742] calling hisi_drm_platform_driver_init+0x0/0x20 @ 1 >>>>>>> [ 2.411790] [drm] Initialized hisi-drm 1.0.0 20141224 on minor 0 >>>>>>> [ 2.411893] initcall hisi_drm_platform_driver_init+0x0/0x20 >>>>>>> returned 0 after 1108 usecs >>>>>>> [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >>>>>>> encoder i2c client >>>>>>> [ 3.546316] [drm] HDMI: new_status=1,old_status=2,hpd=1,dpms=3 >>>>>>> [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block 0 >>>>>>> invalid. >>>>>>> [ 3.602469] [drm] HDMI: mode=0,format_422=0,format_ycbcr=0 >>>>>>> [ 3.603762] [drm] May has one empty edid block! >>>>>>> [ 3.624268] [drm] >>>>>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>>>>> [ 3.624270] [drm] mipi_init , exit success! >>>>>>> [ 3.654185] hisi-drm smb:display-subsystem: fb0: frame buffer >>>> device >>>>>>> [ 3.654192] hisi-drm smb:display-subsystem: registered panic >>>>>>> notifier >>>>>>> [ 43.134240] [drm] phystopstateclklane is not ready. >>>>>>> [ 43.134350] [drm] >>>>>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>>>>> [ 43.134350] [drm] mipi_init , exit success! >>>>>>> >>>>>>> Xorg.0.log error setting DRM version is gone. >>>>>>> >>>>>>> [ 43.134] (==) RandR enabled >>>>>>> [ 43.158] (II) SELinux: Disabled on system >>>>>>> [ 43.161] (II) AIGLX: Screen 0 is not DRI2 capable >>>>>>> [ 43.161] (EE) AIGLX: reverting to software rendering >>>>>>> [ 43.173] (II) AIGLX: Loaded and initialized swrast >>>>>>> [ 43.173] (II) GLX: Initialized DRISWRAST GL provider for >>>>>>> screen 0 >>>>>>> >>>>>>> Why do these errors occur? >>>>>>> [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >>>>>>> encoder i2c client >> This is not a problem, the dsi module is waiting for HDMI module. >> When dsi module can't find HDMI slave encoder module it will return >> -EPROBE_DEFER to deffer probe. >> After the HDMI module has been initialized. This error msg would not >> come again. >>>>>>> [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block 0 >>>>>>> invalid. >> EDID error doesn't matter now. Due to the unfixed signal issue, now >> we explicitly set the 720P timing parameters. So the timing >> parameters doesn't come from EDID. > > Hello - this is in fact a major problem for us. We want to make the > HDMI work “properly” with all monitors. We also need to investigate > the possible SoC clock timing issue identified by Lars at Analog > Devices. Therefore we want to enable the EDID data so that we can then > test different display timings and configurations. > To do testing, characterization and validation of different monitor > timings we also need a command line tool for debugging to enable us to > change the DSI timings and clock set ups on the SoC (see Lars emails) > for different displays. Here is the use case: > > 1. Read EDID information on boot > 2. Boot up in known working 720p configuration (this is what happens > today) > 3. User reads the EDID data using dmesg > 4. Users logs in from remote PC using ssh > 5. Using the EDID information and a debug tool which can adjust clock > settings and DSI output configuration the user sets the monitor > timings for different supported frequency, no of pixels, lines etc. > The debug tool makes the appropriate changes in the SoC and the ADV7533. > 6. User records whether the monitor is working correctly > 7. If the monitor fails the user can go back to the known working 720p > setup using the debug tool. > > This will help us to characterize which timing setups work and which > fail so that we can find the root cause of HDMI not working at > different frequencies/configurations. > Can you help on this? Yes, I can read EDID properly with my local patch, i'll push this patch to 96boards' Github kernel as soon as possible. Such a debug tool is something like the "modetest" tool in libdrm. I'll try it. But, the import fact is that: Recent days i and our SoC guys are analyzing the HDMI signal issue. We have tested many mode timings on TV monitors and PC monitors and we found very a few mode timings can work, including the 720P. SoC guys said that TV monitors are follow the CEA 681 standard and our SoC can't math this standard and during our SoC design phase HDMI is not taken into account. I'm afraid this signal can't be fixed and our SoC can't support HDMI well. > >>>>>>> [ 43.134240] [drm] phystopstateclklane is not ready. >>>>>>> >>>>>>> Out of my depth here, punting to HiSilicon engineers. Guodong can >>>>>>> you take up these errors with HiSilicon please. >>>>>>> >>>>>>> Attached logs (dmesg, Xorg.0.log) from after every reboot. In text >>>>>>> above you will see: >>>>>>> Reboot (x) -- logs are in directory x if the tarball >>>>>>> >>>>>>> Also attached script (build.sh) I use to rebuild the images for >>>>>>> flashing. It will need some rework as it is pretty custom to my >>>>>>> system. >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> -- >>>>>>> Scott Bambrough >>>>>>> Technical Director, Member Services Linaro >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Benjamin Gaignard >>>>>>> >>>>>>> Graphic Working Group >>>>>>> >>>>>>> Linaro.org <http://Linaro.org> │ Open source software for ARM SoCs >>>>>>> >>>>>>> Follow Linaro: Facebook | Twitter | Blog >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Scott Bambrough >>>>>> Technical Director, Member Services >>>>>> Linaro >>>>> >>>>> >>>>> -- >>>>> >>>>> Benjamin Gaignard >>>>> >>>>> Graphic Working Group >>>>> >>>>> Linaro.org <http://Linaro.org> │ Open source software for ARM SoCs >>>>> >>>>> Follow Linaro: Facebook | Twitter | Blog >>>>> >>>>> >>>> Yeah, I realized that afterwards. Seems like the Analog Device code >>>> in drivers/gpu/drm/i2c/adv7533.c drivers/media/i2c/adv7533.c registers >>>> one. >>>> >>>> See: static int adv7533_probe(struct i2c_client *i2c, const struct >>>> i2c_device_id *id) >>>> adv7533->i2c_main = i2c; >>>> adv7533->i2c_edid = i2c_new_dummy(i2c->adapter, >>>> edid_i2c_addr >> >>>> 1); >>>> if (!adv7533->i2c_edid) >>>> return -ENOMEM; >>>> >>>> If I grep through the dmesg output: >>>> >>>> scottb@eagle:~/tmp/logs/3$ grep "adv7533\|drm" dmesg.txt >>>> [ 2.410636] calling drm_core_init+0x0/0x12c @ 1 >>>> [ 2.410705] [drm] Initialized drm 1.1.0 20060810 >>>> [ 2.410720] initcall drm_core_init+0x0/0x12c returned 0 after 69 >>>> usecs >>>> [ 2.410742] calling hisi_drm_platform_driver_init+0x0/0x20 @ 1 >>>> [ 2.411790] [drm] Initialized hisi-drm 1.0.0 20141224 on minor 0 >>>> [ 2.411893] initcall hisi_drm_platform_driver_init+0x0/0x20 >>>> returned 0 after 1108 usecs >>>> [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >>>> encoder i2c client >>>> [ 2.420194] calling adv7533_init+0x0/0x24 @ 1 >>>> [ 2.420254] initcall adv7533_init+0x0/0x24 returned 0 after 44 usecs >>>> [ 3.546316] [drm] HDMI: new_status=1,old_status=2,hpd=1,dpms=3 >>>> [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block 0 >>>> invalid. >>>> [ 3.602469] [drm] HDMI: mode=0,format_422=0,format_ycbcr=0 >>>> [ 3.603762] [drm] May has one empty edid block! >>>> [ 3.624268] [drm] >>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>> [ 3.624270] [drm] mipi_init , exit success! >>>> [ 3.654185] hisi-drm smb:display-subsystem: fb0: frame buffer >>>> device >>>> [ 3.654192] hisi-drm smb:display-subsystem: registered panic >>>> notifier >>>> [ 43.134240] [drm] phystopstateclklane is not ready. >>>> [ 43.134350] [drm] >>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>> [ 43.134350] [drm] mipi_init , exit success! >>>> >>>> It appears the HiSilicon DRM driver is initialized, then the ADV7533. >>>> Could it just be the init order is wrong? >>>> >>>> [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >>>> encoder i2c client >>>> The above error occurs before the ADV7533 driver is initialized. >>>> >>>> [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block 0 >>>> invalid. >>>> [ 3.602469] [drm] HDMI: mode=0,format_422=0,format_ycbcr=0 >>>> [ 3.603762] [drm] May has one empty edid block! >>>> >>>> The above errors stem from a call to: >>>> static int adv7533_get_modes(struct drm_encoder *encoder, struct >>>> drm_connector *connector) >>>> >>>> [ 3.654185] hisi-drm smb:display-subsystem: fb0: frame buffer >>>> device >>>> [ 3.654192] hisi-drm smb:display-subsystem: registered panic >>>> notifier >>>> >>>> These indicate the framebuffer is being created. These stem from a >>>> call to: >>>> static int drm_fb_helper_single_fb_probe(struct drm_fb_helper >>>> *fb_helper, int preferred_bpp) >>>> >>>> which is called from: >>>> bool drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int >>>> bpp_sel) >>>> >>>> which is called from: >>>> static struct hisi_drm_fbdev *hisi_drm_fbdev_create(struct >>>> drm_device *dev, >>>> unsigned int preferred_bpp, unsigned int num_crtc, >>>> unsigned int max_conn_count) >>>> >>>> Another thing I found odd is mipi_init seems to be called twice: Why? >>>> >>>> [ 3.624268] [drm] >>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>> [ 3.624270] [drm] mipi_init , exit success! >>>> >>>> [ 43.134350] [drm] >>>> mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >>>> [ 43.134350] [drm] mipi_init , exit success! >>>> >>>> mipi_init is called from: >>>> static int hisi_dsi_init(struct hisi_dsi *dsi) >>>> >>>> which is called from: >>>> static int hisi_dsi_enable(struct hisi_dsi *dsi) >>>> >>>> which is called from: >>>> static void hisi_drm_encoder_dpms(struct drm_encoder *encoder, int >>>> mode) >>>> when mode = DRM_MODE_DPMS_ON >>>> >>>> There is a corresponding >>>> static int hisi_dsi_disable(struct hisi_dsi *dsi) >>>> called when mode is one of DRM_MODE_DPMS_STANDBY, >>>> DRM_MODE_DPMS_SUSPEND, DRM_MODE_DPMS_OFF >>>> >>>> It does nothing however: >>>> >>>> static int hisi_dsi_disable(struct hisi_dsi *dsi) >>>> { >>>> DRM_DEBUG_DRIVER("enter.\n"); >>>> DRM_DEBUG_DRIVER("exit success.\n"); >>>> return 0; >>>> } >>>> >>>> [ 43.134240] [drm] phystopstateclklane is not ready. >>>> This error is from mipi_init. The first time through mipi_init it >>>> doesn't occur, it does on the second time though. >>>> Seems to indicate a problem with the clocks for the mipi dsi data >>>> lanes. >>>> >>>> I really think we need to sort this out. >>>> >>>> Scott >>>> >>>> -- >>>> Scott Bambrough >>>> Technical Director, Member Services >>>> Linaro >> Anyway, I'll take a look at the latest debian img to see if the >> "fail to load " problem has someting about the drm driver changes >> during recent period. > > Thanks very much - the failure happened when the HDMI code was changed > to the DRM driver. If this can be fixed we can again bring up the GUI > and test Mali GPU acceleration. > > Kind regards > George > >> Best regards, >> -Xinliang Liu >

8 years, 2 months

1
0
0 0

Re: [Dev] X fails to load on current alip image....

by Scott Bambrough

On Thu, Mar 26, 2015 at 3:03 PM, Benjamin Gaignard <benjamin.gaignard(a)linaro.org> wrote: > It could be simple call to an i2c adapter. > For example it is done like this in sti drm/kms driver: > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drive… > > Benjamin > > Le jeudi 26 mars 2015, Scott Bambrough <scott.bambrough(a)linaro.org> a écrit > : > >> We have no hdmi ddc client in the kernel. I suspect this is the >> patches that HiSilicon needs to give us Guodong. >> >> Scott >> >> On Thu, Mar 26, 2015 at 1:58 PM, Tom Gall <tgall(a)gentoo.org> wrote: >> > FYI >> > >> > Advise from Benjamin. >> > >> > Begin forwarded message: >> > >> > Date: March 26, 2015 at 8:57:34 AM PDT >> > Subject: Re: [Dev] X fails to load on current alip image.... >> > From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> >> > To: Tom Gall <tgall(a)gentoo.org> >> > >> > Hi, >> > >> > not sound familiar but I think that the hdmi ddc client isn't set on >> > the correct i2c bus so EDID can't be retrieved. >> > >> > I suggest to check if the hdmi ddc is set on the correct i2c bus and >> > if the dispaly is well connected. >> > >> > Regards, >> > Benjamin >> > >> > 2015-03-26 16:12 GMT+01:00 Tom Gall <tgall(a)gentoo.org>: >> > >> > Hi Benjamin, >> > >> > Does the drm error below look familiar? >> > >> > [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >> > encoder i2c client >> > >> > Is that a real error or is there something else to look at? >> > >> > Thanks! >> > Tom >> > >> > Begin forwarded message: >> > >> > From: Scott Bambrough <scott.bambrough(a)linaro.org> >> > Subject: [Dev] X fails to load on current alip image.... >> > To: <dev(a)lists.96boards.org> >> > Date: March 26, 2015 at 7:21:51 AM PDT >> > >> > I had a look at this failure, debugged this a bit... >> > >> > Started with latest snapshot (135), X fails to load. >> > >> > Rebuild kernel with the latest git, hikey-mali branch >> > Rebuild boot and system images using latest kernel, setup networking >> > via eth0 by default so I can ssh in. >> > Flash boot and system partitions using rebuilt images. >> > Reboot (1) >> > >> > Looking into Xorg.0.log see the following error: >> > >> > [ 60.310] (==) RandR enabled >> > [ 60.333] (II) SELinux: Disabled on system >> > [ 60.336] (II) AIGLX: Screen 0 is not DRI2 capable >> > [ 60.336] (EE) AIGLX: reverting to software rendering >> > [ 60.336] (EE) AIGLX error: dlopen of >> > /usr/lib/aarch64-linux-gnu/dri/swrast_dri.so failed >> > (/usr/lib/aarch64-linux-gnu/dri/swrast_dri.so: cannot open shared >> > object file: No such file or directory) >> > [ 60.336] (EE) GLX: could not load software renderer >> > [ 60.336] (II) GLX: no usable GL providers found for screen 0 >> > [ 60.426] (II) config/udev: Adding drm device (/dev/dri/card0) >> > [ 60.426] (II) xfree86: Adding drm device (/dev/dri/card0) >> > [ 60.429] (EE) /dev/dri/card0: failed to set DRM interface version >> > 1.4: Invalid argument >> > [ 60.590] (EE) Server terminated successfully (0). Closing log file. >> > >> > Solve that error by installing the following package: >> > # apt-get install libgl1-mesa-dri >> > >> > Reboot (2) >> > Missing shared library is found. >> > >> > [ 43.500] (==) RandR enabled >> > [ 43.523] (II) SELinux: Disabled on system >> > [ 43.526] (II) AIGLX: Screen 0 is not DRI2 capable >> > [ 43.526] (EE) AIGLX: reverting to software rendering >> > [ 44.621] (II) AIGLX: Loaded and initialized swrast >> > [ 44.621] (II) GLX: Initialized DRISWRAST GL provider for screen 0 >> > [ 44.970] (II) config/udev: Adding drm device (/dev/dri/card0) >> > [ 44.971] (II) xfree86: Adding drm device (/dev/dri/card0) >> > [ 44.973] (EE) /dev/dri/card0: failed to set DRM interface version >> > 1.4: Invalid argument >> > >> > Why the error "/dev/dri/card0: failed to set DRM interface version >> > 1.4: Invalid argument"? >> > dmesg output has the following error >> > >> > [ 44.985050] ------------[ cut here ]------------ >> > [ 44.985082] WARNING: CPU: 1 PID: 1453 at >> > /media/scottb/linaro/hikey/source/linux/drivers/gpu/drm/drm_ioctl.c:143 >> > drm_setversion+0x168/0x16c() >> > [ 44.985095] No drm_driver.set_busid() implementation provided by >> > hisi_drm_driver. Use drm_dev_set_unique() to set the unique name >> > explicitly. >> > [ 44.985100] Modules linked in: >> > [ 44.985106] btwilink bluetooth st_drv mali wl18xx wlcore mac80211 >> > cfg80211 rfkill wlcore_sdio >> > [ 44.985136] CPU: 1 PID: 1453 Comm: Xorg Tainted: G W >> > 3.18.0linaro-hikey+ #3 >> > [ 44.985141] Call trace: >> > [ 44.987598] [<ffffffc000088538>] dump_backtrace+0x0/0x124 >> > [ 44.987606] [<ffffffc00008866c>] show_stack+0x10/0x1c >> > [ 44.987616] [<ffffffc000806bfc>] dump_stack+0x74/0xb8 >> > [ 44.987625] [<ffffffc0000afdb4>] warn_slowpath_common+0x90/0xb8 >> > [ 44.987631] [<ffffffc0000afe28>] warn_slowpath_fmt+0x4c/0x58 >> > [ 44.987639] [<ffffffc0004eaec4>] drm_setversion+0x164/0x16c >> > [ 44.987646] [<ffffffc0004eaaa0>] drm_ioctl+0x254/0x4d0 >> > [ 44.987656] [<ffffffc0001d216c>] do_vfs_ioctl+0x368/0x5b0 >> > [ 44.987663] [<ffffffc0001d2434>] SyS_ioctl+0x80/0x98 >> > [ 44.987669] ---[ end trace bf426acc001551e5 ]--- >> > >> > Solve that error by applying the following patch: >> > >> > diff --git a/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >> > b/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >> > index 987c530..b646bab 100644 >> > --- a/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >> > +++ b/drivers/gpu/drm/hisilicon/hisi_drm_drv.c >> > @@ -147,6 +147,7 @@ static struct drm_driver hisi_drm_driver = { >> > | DRIVER_PRIME, >> > .load = hisi_drm_load, >> > .unload = hisi_drm_unload, >> > + .set_busid = drm_platform_set_busid, >> > .fops = &hisi_drm_fops, >> > .name = "hisi-drm", >> > .desc = "Hisilicon Terminal SoCs DRM Driver", >> > >> > Rebuild kernel >> > Rebuild boot partition image with latest kernel and flash to the boot >> > partition of the HiKey >> > Reboot (3) >> > >> > dmesg has the following messages from DRM: >> > >> > linaro@linaro-alip:~/sdcard/xwork/3$ grep drm dmesg.txt >> > [ 2.410636] calling drm_core_init+0x0/0x12c @ 1 >> > [ 2.410705] [drm] Initialized drm 1.1.0 20060810 >> > [ 2.410720] initcall drm_core_init+0x0/0x12c returned 0 after 69 >> > usecs >> > [ 2.410742] calling hisi_drm_platform_driver_init+0x0/0x20 @ 1 >> > [ 2.411790] [drm] Initialized hisi-drm 1.0.0 20141224 on minor 0 >> > [ 2.411893] initcall hisi_drm_platform_driver_init+0x0/0x20 >> > returned 0 after 1108 usecs >> > [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >> > encoder i2c client >> > [ 3.546316] [drm] HDMI: new_status=1,old_status=2,hpd=1,dpms=3 >> > [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block 0 >> > invalid. >> > [ 3.602469] [drm] HDMI: mode=0,format_422=0,format_ycbcr=0 >> > [ 3.603762] [drm] May has one empty edid block! >> > [ 3.624268] [drm] >> > mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >> > [ 3.624270] [drm] mipi_init , exit success! >> > [ 3.654185] hisi-drm smb:display-subsystem: fb0: frame buffer device >> > [ 3.654192] hisi-drm smb:display-subsystem: registered panic notifier >> > [ 43.134240] [drm] phystopstateclklane is not ready. >> > [ 43.134350] [drm] >> > mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 >> > [ 43.134350] [drm] mipi_init , exit success! >> > >> > Xorg.0.log error setting DRM version is gone. >> > >> > [ 43.134] (==) RandR enabled >> > [ 43.158] (II) SELinux: Disabled on system >> > [ 43.161] (II) AIGLX: Screen 0 is not DRI2 capable >> > [ 43.161] (EE) AIGLX: reverting to software rendering >> > [ 43.173] (II) AIGLX: Loaded and initialized swrast >> > [ 43.173] (II) GLX: Initialized DRISWRAST GL provider for screen 0 >> > >> > Why do these errors occur? >> > [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave >> > encoder i2c client >> > [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block 0 >> > invalid. >> > [ 43.134240] [drm] phystopstateclklane is not ready. >> > >> > Out of my depth here, punting to HiSilicon engineers. Guodong can >> > you take up these errors with HiSilicon please. >> > >> > Attached logs (dmesg, Xorg.0.log) from after every reboot. In text >> > above you will see: >> > Reboot (x) -- logs are in directory x if the tarball >> > >> > Also attached script (build.sh) I use to rebuild the images for >> > flashing. It will need some rework as it is pretty custom to my >> > system. >> > >> > Scott >> > >> > -- >> > Scott Bambrough >> > Technical Director, Member Services >> > Linaro >> > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > Benjamin Gaignard >> > >> > Graphic Working Group >> > >> > Linaro.org │ Open source software for ARM SoCs >> > >> > Follow Linaro: Facebook | Twitter | Blog >> > >> > >> >> >> >> -- >> Scott Bambrough >> Technical Director, Member Services >> Linaro > > > > -- > > Benjamin Gaignard > > Graphic Working Group > > Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: Facebook | Twitter | Blog > > Yeah, I realized that afterwards. Seems like the Analog Device code in drivers/gpu/drm/i2c/adv7533.c drivers/media/i2c/adv7533.c registers one. See: static int adv7533_probe(struct i2c_client *i2c, const struct i2c_device_id *id) adv7533->i2c_main = i2c; adv7533->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1); if (!adv7533->i2c_edid) return -ENOMEM; If I grep through the dmesg output: scottb@eagle:~/tmp/logs/3$ grep "adv7533\|drm" dmesg.txt [ 2.410636] calling drm_core_init+0x0/0x12c @ 1 [ 2.410705] [drm] Initialized drm 1.1.0 20060810 [ 2.410720] initcall drm_core_init+0x0/0x12c returned 0 after 69 usecs [ 2.410742] calling hisi_drm_platform_driver_init+0x0/0x20 @ 1 [ 2.411790] [drm] Initialized hisi-drm 1.0.0 20141224 on minor 0 [ 2.411893] initcall hisi_drm_platform_driver_init+0x0/0x20 returned 0 after 1108 usecs [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave encoder i2c client [ 2.420194] calling adv7533_init+0x0/0x24 @ 1 [ 2.420254] initcall adv7533_init+0x0/0x24 returned 0 after 44 usecs [ 3.546316] [drm] HDMI: new_status=1,old_status=2,hpd=1,dpms=3 [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block 0 invalid. [ 3.602469] [drm] HDMI: mode=0,format_422=0,format_ycbcr=0 [ 3.603762] [drm] May has one empty edid block! [ 3.624268] [drm] mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 [ 3.624270] [drm] mipi_init , exit success! [ 3.654185] hisi-drm smb:display-subsystem: fb0: frame buffer device [ 3.654192] hisi-drm smb:display-subsystem: registered panic notifier [ 43.134240] [drm] phystopstateclklane is not ready. [ 43.134350] [drm] mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 [ 43.134350] [drm] mipi_init , exit success! It appears the HiSilicon DRM driver is initialized, then the ADV7533. Could it just be the init order is wrong? [ 2.412661] [drm:hisi_dsi_probe] *ERROR* failed to find slave encoder i2c client The above error occurs before the ADV7533 driver is initialized. [ 3.602363] hisi-drm smb:display-subsystem: DSI-1: EDID block 0 invalid. [ 3.602469] [drm] HDMI: mode=0,format_422=0,format_ycbcr=0 [ 3.603762] [drm] May has one empty edid block! The above errors stem from a call to: static int adv7533_get_modes(struct drm_encoder *encoder, struct drm_connector *connector) [ 3.654185] hisi-drm smb:display-subsystem: fb0: frame buffer device [ 3.654192] hisi-drm smb:display-subsystem: registered panic notifier These indicate the framebuffer is being created. These stem from a call to: static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper, int preferred_bpp) which is called from: bool drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel) which is called from: static struct hisi_drm_fbdev *hisi_drm_fbdev_create(struct drm_device *dev, unsigned int preferred_bpp, unsigned int num_crtc, unsigned int max_conn_count) Another thing I found odd is mipi_init seems to be called twice: Why? [ 3.624268] [drm] mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 [ 3.624270] [drm] mipi_init , exit success! [ 43.134350] [drm] mipi_init,pixcel_clk=75,dphy_freq=641,hsa=42,hbp=117,hline=1760 [ 43.134350] [drm] mipi_init , exit success! mipi_init is called from: static int hisi_dsi_init(struct hisi_dsi *dsi) which is called from: static int hisi_dsi_enable(struct hisi_dsi *dsi) which is called from: static void hisi_drm_encoder_dpms(struct drm_encoder *encoder, int mode) when mode = DRM_MODE_DPMS_ON There is a corresponding static int hisi_dsi_disable(struct hisi_dsi *dsi) called when mode is one of DRM_MODE_DPMS_STANDBY, DRM_MODE_DPMS_SUSPEND, DRM_MODE_DPMS_OFF It does nothing however: static int hisi_dsi_disable(struct hisi_dsi *dsi) { DRM_DEBUG_DRIVER("enter.\n"); DRM_DEBUG_DRIVER("exit success.\n"); return 0; } [ 43.134240] [drm] phystopstateclklane is not ready. This error is from mipi_init. The first time through mipi_init it doesn't occur, it does on the second time though. Seems to indicate a problem with the clocks for the mipi dsi data lanes. I really think we need to sort this out. Scott -- Scott Bambrough Technical Director, Member Services Linaro

8 years, 2 months

3
2
0 0

Mali work yet to be done....

by Scott Bambrough

ANDROID --------------------------------- HiSilicon has provided the following files to Linaro for Android: android/32bit: gralloc.hi6210sft.so, libGLES_mali.so, libion.so android/64bit: gralloc.hi6210sft.so, libGLES_mali.so, libion.so The library "libion.so" is needed for Android L. HiSilicon has some vendor specific interfaces in "gralloc.hi6210sft.so", and the provided implementation of "libion.so" will use those interfaces. /media/scottb/linaro/hikey/android/device/linaro/hikey/device.mk Need to add a appropriate PRODUCT_COPY_FILES macro to this makefile. #Copy Graphics binaries PRODUCT_COPY_FILES += $(call add-to-product-copy-files-if-exists,\ $(LOCAL_PATH)/mali/64bit/libGLES_mali.so:system/lib64/egl/libGLES_mali.so\ $(LOCAL_PATH)/mali/64bit/gralloc.hi6210sft.so:system/lib64/ gralloc.hi6210sft.so\ $(LOCAL_PATH)/mali/64bit/libion.so:system/lib64/libion.so \ $(LOCAL_PATH)/mali/32bit/libGLES_mali.so:system/lib/egl/libGLES_mali.so \ $(LOCAL_PATH)/mali/32bit/gralloc.hi6210sft.so:system/lib/ gralloc.hi6210sft.so \ $(LOCAL_PATH)/mali/32bit/libion.so:system/lib/libion.so) I suspect a set of symlinks like those described for X below are required in /system/lib64 and /system/lib. Not entirely sure how to get these setup. To do: 1. Obtain MALI kernel GPU driver from Guillaume Tucker. 2. Obtain kernel ION driver from HiSilicon LINUX/X11 --------------------------------- HiSilicon has provided the following files to Linaro for Linux/X11: x11/32bit: none x11/64bit: libMali.so (untested) To install the 64bit library (libMali.so) 1. Create the file /etc/ld.so.conf.d/arm64-linux-gnu_EGL.conf. This file should contain the single line: /usr/lib/arm64-linux-gnu/mali-egl 2. Install libMali.so to /usr/lib/arm64-linux-gnu/mali-egl, root:root, 644 3. Create the following symlinks in /usr/lib/arm64-linux-gnu/mali-egl - libEGL.so -> libEGL.so.1.0.0 - libEGL.so.1 -> libEGL.so.1.4 - libEGL.so.1.4 -> libMali.so - libGLESv1_CM.so -> libGLESv1_CM.so.1 - libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.1.0 - libGLESv1_CM.so.1.1.0 -> libMali.so - libGLESv2.so -> libGLESv2.so.2.0.0 - libGLESv2.so.2 -> libGLESv2.so.2.0.0 - libGLESv2.so.2.0.0 -> libMali.so 4. Install an xf86 driver for X.org that will work with the frame buffer. We currently cannot support multiarch for ARM 32-bit code, as we will be able to in Android. For that we need a 32bit driver for Linux/X11 from HiSilicon. To install a 32bit library (libMali.so) 1. Create the file /etc/ld.so.conf.d/arm-linux-gnu_EGL.conf. This file should contain the single line: /usr/lib/arm-linux-gnu/mali-egl 2. Install libMali.so to /usr/lib/arm-linux-gnu/mali-egl, root:root, 644 3. Create the following symlinks in /usr/lib/arm64-linux-gnu/mali-egl - libEGL.so -> libEGL.so.1.0.0 - libEGL.so.1 -> libEGL.so.1.4 - libEGL.so.1.4 -> libMali.so - libGLESv1_CM.so -> libGLESv1_CM.so.1 - libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.1.0 - libGLESv1_CM.so.1.1.0 -> libMali.so - libGLESv2.so -> libGLESv2.so.2.0.0 - libGLESv2.so.2 -> libGLESv2.so.2.0.0 - libGLESv2.so.2.0.0 -> libMali.so To do: 1. Obtain MALI kernel GPU driver from Guillaume Tucker. 2. Obtain 32bit libMali.so for Linux/X11 from HiSilicon. 3. DRM kernel display driver. - To implement and test X11 needed ioctl interfaces. - To integrate some mali private ioctl interfaces, such as dma_buf fb. 4. DRM userspace work. Need a DRM enabled xf86 driver for X.org. - http://cgit.freedesktop.org/xorg/driver/xf86-video-armsoc/ - Expect some related work like that done by ARM as described here: http://lists.x.org/archives/xorg-devel/2012-May/031250.html - There also might be some changes needed in libdrm to add support for the HiKey platform. 5. Fathi to package the Mali libs and create the symlinks required on installation. If I have missed anything or got anything wrong, please feel free to provide additions/corrections. Regards, Scott -- Scott Bambrough Technical Director, Member Services Linaro <http://www.linaro.org>

8 years, 2 months

7
8
0 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

Dev March 2015