Myy Posted October 29, 2017 Posted October 29, 2017 Hmm... I remember that there's a ls and a cat command with U-Boot but their use are quite awkward. Something like ls mmc1:1 / or something like that. Anyway, I'll investigate this tomorrow. Meanwhile, if you can mount your MMC through USB, using the good old ums 0 mmc 1 command and paste the content of /your/mounted/mmc/boot/boot.scr and the content of ls -1 /your/mounted/mmc/boot
Tido Posted October 29, 2017 Posted October 29, 2017 (edited) mmc ? I put the SDcard in the SDcard-Reader, but I cannot read out boot.scr just boot.cmd Weird boot.cmd points to "rk3288-miqi.dtb". # DO NOT EDIT THIS FILE # # Please edit /boot/armbianEnv.txt to set supported parameters # setenv rootdev "/dev/mmcblk0p1" setenv fdt_file "rk3288-miqi.dtb" setenv ramdisk_addr_r "0x21000000" setenv console "ttyS2,115200n8" setenv verbosity "1" itest.b ${devnum} == 0 && echo "U-boot loaded from SD" itest.b ${devnum} == 1 && echo "U-boot loaded from eMMC" if load ${devtype} ${devnum}:1 ${ramdisk_addr_r} /boot/armbianEnv.txt || load ${devtype} ${devnum}:1 ${ramdisk_addr_r} armbianEnv.txt; then env import -t ${ramdisk_addr_r} ${filesize} fi setenv bootargs "consoleblank=0 scandelay root=${rootdev} rw console=${console} rootfstype=ext4 loglevel=${verbosity} rootwait ${extraargs}" ext4load ${devtype} ${devnum}:1 ${fdt_addr_r} /boot/dtb/${fdt_file} || fatload ${devtype} ${devnum}:1 ${fdt_addr_r} dtb/${fdt_file} || ext4load ${devtype} ${devnum}:1 ${fdt_addr_r} dtb/${fdt_file} ext4load ${devtype} ${devnum}:1 ${ramdisk_addr_r} /boot/uInitrd || fatload ${devtype} ${devnum}:1 ${ramdisk_addr_r} uInitrd || ext4load ${devtype} ${devnum}:1 ${ramdisk_addr_r} uInitrd ext4load ${devtype} ${devnum}:1 ${kernel_addr_r} /boot/zImage || fatload ${devtype} ${devnum}:1 ${kernel_addr_r} zImage || ext4load ${devtype} ${devnum}:1 ${kernel_addr_r} zImage bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Whereas the armbianEnv.txt to: rk3288-miniarm.dtb @TonyMac32, is this intention or did I do something bogus ? verbosity=1 fdt_file=rk3288-miniarm.dtb rootdev=UUID=47abe137-7697-490d-b4ed-6212d35ea51f rootfstype=ext4 tido@medion:/media/tido/47abe137-7697-490d-b4ed-6212d35ea51f/boot$ ll insgesamt 21M -rw-r--r-- 1 root root 106 Jul 23 08:34 armbianEnv.txt -rw-r--r-- 1 root root 1.6K Jul 23 08:30 armbian_first_run.txt -rw-r--r-- 1 root root 38K Jul 23 08:30 boot.bmp -rw-r--r-- 1 root root 1.4K Jul 23 08:25 boot.cmd -rw-r--r-- 1 root root 4.8K Jul 23 08:30 boot-desktop.png -rw-r--r-- 1 root root 1.5K Jul 23 08:34 boot.scr -rw-r--r-- 1 root root 136K Okt 22 02:02 config-4.13.9-rockchip lrwxrwxrwx 1 root root 19 Okt 22 09:00 dtb -> dtb-4.13.9-rockchip drwxr-xr-x 2 root root 4.0K Jul 31 18:04 dtb-4.12.3-rockchip drwxr-xr-x 2 root root 4.0K Okt 22 16:24 dtb-4.13.2-rockchip drwxr-xr-x 2 root root 4.0K Okt 22 08:59 dtb-4.13.9-rockchip lrwxrwxrwx 1 root root 19 Okt 22 08:26 dtb.old -> dtb-4.13.8-rockchip -rw-r--r-- 1 root root 4.4M Okt 29 10:36 initrd.img-4.13.9-rockchip -rw-r--r-- 1 root root 0 Okt 22 09:00 .next -rw-r--r-- 1 root root 3.5M Okt 22 02:02 System.map-4.13.9-rockchip lrwxrwxrwx 1 root root 23 Okt 29 10:36 uInitrd -> uInitrd-4.13.9-rockchip -rw-r--r-- 1 root root 4.4M Okt 29 10:36 uInitrd-4.13.9-rockchip -rwxr-xr-x 1 root root 7.8M Okt 29 22:23 vmlinuz-4.13.9-rockchip lrwxrwxrwx 1 root root 23 Okt 22 09:00 zImage -> vmlinuz-4.13.9-rockchip I have edited armbianEnv.txt to use tinker.dtb, but did not help Edited October 29, 2017 by Tido last line added
TonyMac32 Posted October 30, 2017 Posted October 30, 2017 tinker.dtb is not the dtb used with Armbian, the reason being twofold, firstly the mainline dtb keeps getting edited, and secondly the 4.4 vendor image uses rk3288-miniarm.dtb, so what I've essentially done is create a dtb from the mainline one that includes various fixes/adjustments without wondering if the next kernel patchlevel is going to break it, and avoiding renaming everything from the vendor/scripts. I have to confess that I'm not 100% on how the armbianenv.txt plays into things, and haven't tried swapping out kernels for another.
Tido Posted October 30, 2017 Posted October 30, 2017 (edited) Thank you for the information. I remember reading about it, but where to find in the forum Yesterday evening I had said, armbianEnv.txt overrides entries in boot.bmp. That said I read now this: https://docs.armbian.com/User-Guide_Allwinner_overlays/#example-bootarmbianenvtxt-contents and now I am not sure. I would be helpful if @zador.blood.stained or @Igor would add 1-2 lines in the armbianEnv.txt like: armbianEnv.txt is currently used to override entries of boot.bmp without the necessity of recompiling it. As an add-on to the before mentioned function it shall be possible "in the future" to handle OVERLAYS in here as well. You will find more information https://docs.armbian.com search for: armbianEnv (2017 October) A search for armbianenv in the forum discovered.. been there, done that - sorry Tony, it was late. Edited October 30, 2017 by Tido Search..
Myy Posted October 30, 2017 Posted October 30, 2017 From what I'm seeing, it looks like you only have 4.13.9 kernels... At worst, you can add an extlinux/extlinux.conf and have U-boot uses that instead. You'll lose the clean update system and will have to edit your extlinux.conf by hand every time you want to add a boot option, though. I'll try to provide an example tomorrow.
Tido Posted October 30, 2017 Posted October 30, 2017 I don't think so, there is a sym link from zImage -> vmlinuz-4.13.9-rockchip 7.8M Okt 29 22:23 vmlinuz-4.13.9-rockchip
TonyMac32 Posted October 30, 2017 Posted October 30, 2017 The "Dev" images are 4.14, but they must be manually built by the user.
Tido Posted October 31, 2017 Posted October 31, 2017 I downloaded the git repo of Myy and copied some files into armbian eg. zImage. I believe because of the sym-link it looks like it is 4.13 but the date of the changed Nightlys are already 4.14 rc6 1
TonyMac32 Posted October 31, 2017 Posted October 31, 2017 I feel like I already knew that, problem is I wind up building stuff all the time and almost never just update.
Myy Posted October 31, 2017 Posted October 31, 2017 Did you try using the rk3288-tinker.dtb provided with my build, or a 4.14.x ready rk3288-miniarm.dtb ? If you use a 4.13 or lower version DTB, it might fail to boot due to Rockchip 32 bits DTS using 64 bits addressing now, in order to use LPAE on some 32 bits boards. LPAE provides the ability to use more than 4 GB of memory on 32 bits systems, through magic, memory windows and ugly hacks. Anyway, I tested my latest release (4.14.0-rc7) with glmark2 and the Rockchip's r14p0-wayland user-space binary drivers and it works. I'll try to install Rockchip xserver and test glmark2 on X11 this week, if I got the time. During these tests, I discovered the magic of chvt, which changes the current virtual terminal displayed on the screen, which is very useful when you have control on a machine with SSH access, but no USB keyboard plugged on the machine, and want to switch to a terminal from X11. So basically instead of trying to find a keyboard, plug it and hit CTRL+ALT+F1, you just have to type : sudo chvt 1 I also checked that using a shitty micro-USB cable will cause the MiQi to reboot instantly when doing 3D intensive work. Yay ! Remember kids, don't do drugs use bad micro-USB cables ! 1
Tido Posted October 31, 2017 Posted October 31, 2017 8 hours ago, Myy said: Did you try using the rk3288-tinker.dtb provided with my build, or a 4.14.x ready rk3288-miniarm.dtb ? I have copied your rk3288-tinker.dtb, serveral times and renamed it to: rk3288-miqi.dtb rk3288-miniarm.dtb It wouldn't boot. Well, I copied all your files, also the zImage - is there a way to proof which version/file I have beside the filename ? Phuu, sounds complicated :-) I believe I have done it right as the date of the file changed. Uuups, yesterday night I already copied a fresh 4.14-rc6 on it - so I cannot do the thing from StackOverFlow. Holy cow, I am impressed !!! I attach this nightly build (already booted, just sitting there, plug the HDMI-DVI cable in) to my Fujitsu Siemens P19-1s 19" 1280x1024 and it just works. htop reports 203Mb used, 1,5% CPU load, 44° C no cooler attached.
TonyMac32 Posted October 31, 2017 Posted October 31, 2017 So was this the Armbian nightly or the Myy kernel? I only have 720p, 1080p, and 4k test monitors, so haven't been able to test any other "strange ones"
Tido Posted October 31, 2017 Posted October 31, 2017 (edited) You must be kidding me, 1280x1024 is(was) one of the most common resolutions (5:4) - not this shitty 16:9. As this display only comes with DVI-Port I have a HDMI-to-DVI cable attached. And it works out of the box with the latest nightly of Armbian_5.34._Tinkerboard_Ubuntu_xenial_dev_4.14.0-rc6_desktop.img So it must be getting EDID right. Next step is to throw Myy's kernel at it common resolutions, nowadays and before: 1920x1080 Full HD 1280x720 HD 1280x1024 SXGA 1024x768 XGA 800x600 SVGA 640x480 VGA Edited October 31, 2017 by Tido common resolutions, nowadays and before
Myy Posted October 31, 2017 Posted October 31, 2017 The only thing that *might* generate issues would be the initrd. But I don't think that it would cause the system to not boot and not print anything on the serial output. Now, since you got a working kernel, try to list the modules used by your system, just in case |`・ω・)ノ . Also try to use the rk3288-miniarm.dtb too, since we're sure that it works.
Tido Posted October 31, 2017 Posted October 31, 2017 (edited) root@tinkerboard:~# lsmod Module Size Used by snd_soc_hdmi_codec 16384 0 r8723bs 548864 0 syscon_reboot_mode 16384 0 reboot_mode 16384 1 syscon_reboot_mode rk_crypto 24576 0 at24 16384 0 mali_kbase 339968 0 dw_hdmi_i2s_audio 16384 0 So I will copy all your files, except the DTB and reboot Edited October 31, 2017 by Tido copy
Myy Posted October 31, 2017 Posted October 31, 2017 I don't have my MiQi here so I can't paste the extlinux/extlinux.conf I'm using. Still, instead of copying zImage bluntly, you could do cp zImage /boot/Myy-Kernel and then configure your bootloader to boot Myy-Kernel instead of zImage
Myy Posted October 31, 2017 Posted October 31, 2017 Also try to comment the initrd line in the boot.scr if it doesn't boot, just to see if that changes anything...
Tido Posted October 31, 2017 Posted October 31, 2017 (edited) I have only replaced the kernel, put it to /boot/myy-kernel/ If I had a hex-editor, could I change the file boot.scr without the detour of: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr ? Spoiler U-Boot SPL 2017.09-armbian (Oct 30 2017 - 02:49:58) Returning to boot ROM... U-Boot 2017.09-armbian (Oct 30 2017 - 02:49:58 +0100) Model: Tinker-RK3288 DRAM: 2 GiB MMC: dwmmc@ff0c0000: 1 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Tinker-RK3288 Net: eth0: ethernet@ff290000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 1496 bytes read in 37 ms (39.1 KiB/s) ## Executing script at 00000000 U-boot loaded from eMMC 155 bytes read in 33 ms (3.9 KiB/s) 43195 bytes read in 70 ms (602.5 KiB/s) 4493470 bytes read in 250 ms (17.1 MiB/s) 8168664 bytes read in 390 ms (20 MiB/s) ## Loading init Ramdisk from Legacy Image at 21000000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4493406 Bytes = 4.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to 0fbb6000, end 0ffff05e ... OK Loading Device Tree to 0fba8000, end 0fbb58ba ... OK Starting kernel ... Edit: When this happens, the SoC gets as hot, that you can just hold the finger on it, almost hurts. This is around 60°C Okay so I will comment now: ext4load ${devtype} ${devnum}:1 ${ramdisk_addr_r} /boot/uInitrd || fatload ${devtype} ${devnum}:1 ${ramdisk_addr_r} uInitrd || ext4load ${devtype} ${devnum}:1 ${ramdisk_addr_r} uInitrd Edited October 31, 2017 by Tido heat
Myy Posted October 31, 2017 Posted October 31, 2017 Ah, yeah, the boot.scr is the binary file and boot.cmd is the one used to generate it so comment the ramdisk line in the boot.cmd and regenarate the boot.scr... if the kernel doesn't boot of course.
Tido Posted October 31, 2017 Posted October 31, 2017 the output of 'screen' is scrumbled: Spoiler t SP30-49)tunoot17.09-arm 2 - 9:01odkMC:wmmf01* Wing - bad us: r tny topboswitch to partit 0, mnt mmcFound U-Boot script 1497 byrd (s in 0 5 byt1 ms (4.9 43195 m938 KiB816byms (MiB/s Wr Rdisk Imae ein SCRIILcinstinSB..rlUSB1 : _oeou_ooroiou_oorstt_oreho: Tiut! dwc_otg_core_host_t: Tic_otg_cho: _ocoi: u dwg_hotmeann b fe 2 sanus 1 ic ce Df :n r9in Pneoo
Myy Posted October 31, 2017 Posted October 31, 2017 The boot went : Tiut ! I guess that you get nothing after that ?
TonyMac32 Posted October 31, 2017 Posted October 31, 2017 @Tido surely you're not so serious as all that? I haven't had a non-16x9 monitor since I abandoned the VGA cable. The amazing amount of unnecessary extraneous noise aside, I'm glad to see EDID is functioning properly. Now, I will continue to give candy to strangers as part of Halloween. And maybe freeze to death.
Myy Posted November 1, 2017 Posted November 1, 2017 And that's how @TonyMac32 became a SnowMan. Anyway, I guess I'll have to find a Tinkerboard during December, since that clearly needs special testing.
Tido Posted November 1, 2017 Posted November 1, 2017 Why not tweaking the 'next' armbian branch - it is marked and highlighted as WIP ?
Myy Posted November 2, 2017 Posted November 2, 2017 Now that I have access to my MiQi, here's the /boot/extlinux/extlinux.conf I'm using to boot my kernels : root@miqi:~# cat /boot/extlinux/extlinux.conf label kernel-4.4 kernel /boot/zImage fdt /boot/rk3288-miqi.dtb append earlyprintk console=ttyS2,115200n8 rw root=/dev/mmcblk1p1 rootfstype=ext4 init=/sbin/init Note that I'm not using a /boot partition. Anyway, here's ls -l /boot root@miqi:~# ls -l /boot total 92172 -rw-r--r-- 1 root root 78 May 3 2017 armbianEnv.txt -rw-r--r-- 1 root root 1557 May 3 2017 armbian_first_run.txt -rw-r--r-- 1 root root 129427 May 3 2017 config-4.11.0+ -rw-r--r-- 1 root root 155497 Sep 12 00:36 config-4.13.0-RockMyy-XIII -rw-r--r-- 1 root root 155497 Sep 10 19:44 config-4.13.0-RockMyy-XIII.old -rw-r--r-- 1 root root 156664 Sep 16 07:53 config-4.14.0-rc4-RockMyy-XIV-A-Myy-Reborn -rw-r--r-- 1 root root 156664 Sep 16 07:36 config-4.14.0-rc4-RockMyy-XIV-Myy-Returns -rw-r--r-- 1 root root 156664 Nov 2 09:05 config-4.14.0-rc7-RockMyy-XIV-A-Myy-Reborn -rw-r--r-- 1 root root 125351 Aug 12 17:31 config-4.4.81-rockchip drwxr-xr-x 2 root root 4096 Jun 20 15:42 dtb-4.11.0-rockchip drwxr-xr-x 2 root root 4096 Aug 7 16:50 dtb-4.13.0-rockchip drwxr-xr-x 2 root root 4096 Aug 18 16:49 dtb-4.4.81-rockchip drwxr-xr-x 2 root root 4096 Sep 12 00:26 extlinux -rw-r--r-- 1 root root 4438628 Oct 30 16:10 initrd.img-4.11.4-rockchip -rw-r--r-- 1 root root 4421353 Aug 18 16:55 initrd.img-4.4.81-rockchip drwx------ 2 root root 4096 Jul 16 22:17 lost+found -rw-r--r-- 1 root root 40525 Nov 2 09:05 rk3288-evb-act8846.dtb -rw-r--r-- 1 root root 40922 Nov 2 09:05 rk3288-evb-rk808.dtb -rw-r--r-- 1 root root 37039 Nov 2 09:05 rk3288-fennec.dtb -rw-r--r-- 1 root root 40777 Nov 2 09:05 rk3288-firefly-beta.dtb -rw-r--r-- 1 root root 40769 Nov 2 09:05 rk3288-firefly.dtb -rw-r--r-- 1 root root 41955 Nov 2 09:05 rk3288-firefly-reload.dtb -rw-r--r-- 1 root root 39656 Nov 2 09:05 rk3288-miqi.dtb -rw-r--r-- 1 root root 41029 Jul 18 16:59 rk3288-miqi.dtb.bak -rw-r--r-- 1 root root 39604 Nov 2 09:05 rk3288-popmetal.dtb -rw-r--r-- 1 root root 37310 Nov 2 09:05 rk3288-r89.dtb -rw-r--r-- 1 root root 40289 Nov 2 09:05 rk3288-rock2-square.dtb -rw-r--r-- 1 root root 41026 Nov 2 09:05 rk3288-tinker.dtb -rw-r--r-- 1 root root 39316 Nov 2 09:05 rk3288-veyron-brain.dtb -rw-r--r-- 1 root root 47442 Nov 2 09:05 rk3288-veyron-jaq.dtb -rw-r--r-- 1 root root 47495 Nov 2 09:05 rk3288-veyron-jerry.dtb -rw-r--r-- 1 root root 39921 Nov 2 09:05 rk3288-veyron-mickey.dtb -rw-r--r-- 1 root root 48314 Nov 2 09:05 rk3288-veyron-minnie.dtb -rw-r--r-- 1 root root 45862 Nov 2 09:05 rk3288-veyron-pinky.dtb -rw-r--r-- 1 root root 47270 Nov 2 09:05 rk3288-veyron-speedy.dtb -rw-r--r-- 1 root root 3702224 Sep 12 00:36 System.map-4.13.0-RockMyy-XIII -rw-r--r-- 1 root root 3702224 Sep 10 19:44 System.map-4.13.0-RockMyy-XIII.old -rw-r--r-- 1 root root 3781860 Sep 16 07:53 System.map-4.14.0-rc4-RockMyy-XIV-A-Myy-Reborn -rw-r--r-- 1 root root 3781964 Sep 16 07:36 System.map-4.14.0-rc4-RockMyy-XIV-Myy-Returns -rw-r--r-- 1 root root 3782323 Nov 2 09:05 System.map-4.14.0-rc7-RockMyy-XIV-A-Myy-Reborn lrwxrwxrwx 1 root root 23 Oct 30 16:10 uInitrd -> uInitrd-4.11.4-rockchip -rw-r--r-- 1 root root 4438692 Oct 30 16:10 uInitrd-4.11.4-rockchip -rw-r--r-- 1 root root 4421417 Aug 18 16:55 uInitrd-4.4.81-rockchip -rw-r--r-- 1 root root 19873868 Sep 10 19:44 vmlinuz-4.13.0-RockMyy-XIII -rw-r--r-- 1 root root 19897976 Sep 16 07:09 vmlinuz-4.14.0-rc4-RockMyy-XIV-Myy-Returns -rwxr-xr-x 1 root root 8039272 Aug 21 05:05 vmlinuz-4.4.81-rockchip -rwxr-xr-x 1 root root 8167960 Nov 2 09:05 zImage And the motd SSH output : __ __ _ ___ _ | \/ (_)/ _ \(_) | |\/| | | | | | | | | | | | |_| | | |_| |_|_|\__\_\_| Welcome to ARMBIAN 5.30 stable Ubuntu 16.04.2 LTS 4.14.0-rc7-RockMyy-XIV-A-Myy-Reborn System load: 0.52 0.19 0.07 Up time: 0 min Memory usage: 7 % of 2009MB IP: 10.100.0.55 CPU temp: 61°C Usage of /: 27% of 15G [ 0 security updates available, 97 updates total: apt upgrade ] Last check: 2017-11-02 09:08 [ General system configuration: armbian-config ] Last login: Mon Oct 30 16:21:04 2017 from 10.100.0.1 To run a command as administrator (user "root"), use "sudo <command>". See "man sudo_root" for details. Anyway, I still have some issues with the HDMI screen that I have to unplug / plug back sometimes. I'll try to see if adding back some the old DRM patches fix the issue. Here's my modules list btw : root@miqi:~# lsmod Module Size Used by bnep 20480 2 mali_kbase 512000 1 dw_hdmi_i2s_audio 16384 0 dw_hdmi_cec 16384 0 rk_crypto 24576 0 Why is the bnep loaded ? Well, that's a good question ! I have no single idea, since there's no Bluetooth chip integrated into the MiQi, as far as I remember. When launching glmark2, you should get that kind of output : root@miqi:~# glmark2-es2-drm ======================================================= glmark2 2017.07 ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-T760 GL_VERSION: OpenGL ES 3.2 v1.r14p0-01rel0-git(966ed26).810f535757d8c9adaaa72f5da29c688e ======================================================= [build] use-vbo=false: FPS: 59 FrameTime: 16.949 ms [build] use-vbo=true:^C FPS: 60 FrameTime: 16.667 ms ======================================================= glmark2 Score: 59 ======================================================= The ^C is due to me hitting CTRL+C. The first batch should be at 59 fps generally, after a cold start.
Tido Posted November 3, 2017 Posted November 3, 2017 On 31.10.2017 at 11:55 PM, TonyMac32 said: surely you're not so serious as all that? I haven't had a non-16x9 monitor since I abandoned the VGA cable. Well, the 1280x1024 I have since ca. 2007 it became retired (spare) in 2013 when I got a Dell IPS 16:10 (16:9) for a desktop is an absolutely NO GO Around 2014 I fixed a 17" 1280x1024 of a friend by replacing the blown up electrolytic capacitors. For my dad we bought around 2008 one of the last 1600x1200 20" display (at that time for a fortune of $800.-) it still runs. So you ask me if I am kidding, not at all. For the company I work, I just got more than 8000 displays 16:10 IPS (1920x1200). But to come back to SBCs. 52pi sells displays with 800x480 up to 1280x800 7". I have ordered this one, but if it won't run on SBC, I can run it on one of my RPi. While I want to use this as a touch-display in combination with a SBC. But while testing and sitting at my desk, I have this 19" 1280x1024 next to me
Tido Posted November 3, 2017 Posted November 3, 2017 On 2.11.2017 at 10:19 AM, Myy said: When launching glmark2 root@tinkerboard:/boot# glmark2-es2-drm Error: Failed to find a suitable DRM device Error: main: Could not initialize canvas Segmentation fault As I can only run armbian kernel properly..
Andrew Shahoff Posted November 4, 2017 Posted November 4, 2017 Hi ! I am so pleased that somebody trying to fix this opengl things for Tinkerboard Can do testing as I do have Tboard and HDMI interface. Hopefully will also pickup 3v serial today. 1
Myy Posted November 4, 2017 Posted November 4, 2017 @Tido What version of glmark2 do you have ? The old versions seemed to have a broken DRM detection system based on some whitelist, that I kind of fixed in the later versions. I highly suggest using the GIT version of glmark2 and uninstalling glmark2 Debian packages for the moment. sudo apt remove glmark2 git clone --depth 1 https://github.com/glmark2/glmark2 cd glmark2 ./waf configure --with-flavors=drm-glesv2 ./waf sudo ./waf install glmark2-es2-drm Also, be sure to execute that version from a TTY (Ctrl+ALT+F1 or chvt 1)
Tido Posted November 5, 2017 Posted November 5, 2017 On 4.11.2017 at 12:24 PM, Myy said: What version of glmark2 do you have ? ii glmark2-data 2014.03+git201 all data files for the glmark2 OpenGL (ES) 2.0 ii glmark2-es2-drm 2014.03+git201 armhf OpenGL ES 2.0 DRM benchmark looks to me I need to follow your instruction to properly test it
Recommended Posts