TonyMac32 528 Posted November 19, 2018 Share Posted November 19, 2018 2 changes are in queue on my workstation, one is u-boot 2018.11, the other is updating the Dev patchset and beginning to iron out 4.19 Kernel. The first I honestly don't see any issues with moving forward, but want people to know about it, the second is a bit of a hairball and I'll need some help with debugging, and in fixing. Detail of changes: U-boot: Currently Meson64 and Odroid C2 are using 2018.05 and 2018.07, respectively. I will be moving all to 2018.11, and eliminating the "specialness" of the Odroid C2 in our build system, so Meson64 will be inheriting the C2 boot script under the "Meson64 name, it will no longer have its own u-boot patch folder/etc. The board will finally be fully integrated into the Meson64 configuration, although it will still have the special Odroid firmware blob (all Amlogic SoC's have their own blobs, so no special changes need made to allow for the C2 to have a different one than the K2) Current Concerns: packaging scripts on 4.14 kernel are not creating a symlinked named "Image" for the updated boot script. I didn't consider that and only caught it today. U-boot is obviously unimpressed. Kernel 4.19: This will eventually become the "Default" kernel, once it has been debugged and proven out, as Amlogic Mainline kernels can now be easily patched with full video decoder support (already done), and Mali support is available (I need to finish integrating that, later date) Current concerns: -HDMI displays seem to be a sore spot, I have 1 that works flawlessly (hilariously a 7" waveshare-like HDMI), while the other needs to be plugged in after boot to work, and an HDMI-DVI adapter one is nonfunctional. (it seems to think it's attached, but no image) - I am getting a million "failed to change cpu frequency: -5" errors again. The clock marked as critical fix is in there, needs verified as it looks different than the old one. - I had to disable CEC entirely to get the system to boot with a display attached, it would fault, reboot, fault, etc. Plugging in a display after boot yielded an oops. No CEC = that problem is gone. Tagging @Neil Armstrong, for tracking if interested/have ideas. I'm using Neil's always helpful meta-meson patchset, these were squirreled away in "next" so I assume they are not complete/some WIP, so this can be some good feedback/etc. No one can break things like an end user. 0 Quote Link to post Share on other sites
Neil Armstrong 16 Posted November 19, 2018 Share Posted November 19, 2018 Hi @TonyMac32! thanks for these reports, I really near 0 report rate on the display support... so it’s cool to have something at least ! If you need to plug the displays after boot is because they depends on the usb 5v which is enabled too late in the boot and the display driver fails to get a correct EDID table for the monitor and falls back to 1024x768 which is not always supported by the small displays. The simplest way is to enable the 5v regulator from u-boot, but it needs a patch. can you give me the /sys/kernel/debug/dri content and the edid of the dvi adapter in /sys/class/dri/HDMI-A-1/edid for the cec issue, no idea at all !! On which board does this happens ? And on which monitor ? for the -5 clock issue, did you apply chewitt’s « clk_div3 » patch aswell ? 0 Quote Link to post Share on other sites
TonyMac32 528 Posted November 19, 2018 Author Share Posted November 19, 2018 Hi @Neil Armstrong, I'm at the day job (interestingly working with my colleagues in Toulouse), I will gather the requested information later, but for what I can answer now: 5 hours ago, Neil Armstrong said: for the cec issue, no idea at all !! On which board does this happens ? And on which monitor ? It happened on both that have issue with hdmi powerup. I did not test the little 7" one until after I'd disabled CEC, since it is usually my "problem monitor". The K2, C2, and Le Potato were affected. 5 hours ago, Neil Armstrong said: for the -5 clock issue, did you apply chewitt’s « clk_div3 » patch aswell ? I did not, but can. I realised they had both been applied while still getting boot loops so I got rid of the old patch early on. 0 Quote Link to post Share on other sites
TonyMac32 528 Posted November 20, 2018 Author Share Posted November 20, 2018 Is there something in particular you want form the the debug/dri folder? I have a "0" folder with some contents EDID's attached, Acer is the HDMI-DVI connected monitor, Samsung is a 27" 4K screen, 7" is, well, an RTD2660H-based 7" hdmi LCD 7InchEDID.txt AcerEDID.txt samsungEDID.txt 0 Quote Link to post Share on other sites
sbc_chrisb 5 Posted November 20, 2018 Share Posted November 20, 2018 Is this the thread were we make requests for config changes for the kernel build? I am going back to rebuild a custom kernel due to missing hidraw and logitech unifying receiver modules. As far as I'm concerned I'm cool with rolling a custom kernel, but I would think I ain't the only dude wanting to use Logitech wireless devices with my board. It would be cool to have these built in as modules. 0 Quote Link to post Share on other sites
TonyMac32 528 Posted November 21, 2018 Author Share Posted November 21, 2018 @Neil Armstrong Odroid C2 booting u-boot 2018.11, kernel 4.19, integrated with Meson64: http://ix.io/1pp7 Link is diagnostic info. [edit] the older patch for fclk_div3 issue resolved the -5 clock issue again. For everyone else, The packaging script on 4.14 still needs adjusted to boot 4.14, but u-boot isn't the problem there, I will push the u-boot update. 0 Quote Link to post Share on other sites
Igor 1970 Posted November 21, 2018 Share Posted November 21, 2018 2 hours ago, TonyMac32 said: The packaging script on 4.14 still needs adjusted to boot 4.14 I looked (quickly) into and its working for me OOB Don't understand what is wrong? How to reproduce? 0 Quote Link to post Share on other sites
TonyMac32 528 Posted November 21, 2018 Author Share Posted November 21, 2018 16 minutes ago, Igor said: I looked (quickly) into and its working for me OOB Don't understand what is wrong? How to reproduce? [edit] Oh wait... @Igor did you test Odroid C2? It didn't really change.. K2/Potato are the affected boards. I have to go for the night, but do you just wipe out the extra packaging file? 0 Quote Link to post Share on other sites
guidol 260 Posted December 3, 2018 Share Posted December 3, 2018 @Igor said on twitter: Help us debug the Meson #arm64 family: #odroidc2 #lepotato #nanopik2-s905 #Linux #kernel update to 4.19.y You can use test images or update to beta repository DEV branch kernel via armbian-config. I did compile the 4.19.y DEV for the C2 ARMBIAN 5.67 user-built Debian GNU/Linux 9 (stretch) 4.19.6-meson64 Linux odroid-c2 4.19.6-meson64 #5.67 SMP PREEMPT Mon Dec 3 13:48:03 +03 2018 aarch64 GNU/Linux and create a github report. I didnt get a video-signal at the HDMI-Port (HDMI-Console-version): Spoiler [ 6.922231] meson-drm d0100000.vpu: CVBS Output connector not available [ 6.951678] meson-dw-hdmi c883a000.hdmi-tx: Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy) [ 6.952215] meson-dw-hdmi c883a000.hdmi-tx: registered DesignWare HDMI I2C bus driver [ 6.952703] meson-drm d0100000.vpu: bound c883a000.hdmi-tx (ops meson_dw_hdmi_ops [meson_dw_hdmi]) [ 7.095335] meson-drm d0100000.vpu: [drm:drm_fb_helper_fbdev_setup [drm_kms_helper]] *ERROR* Failed to set fbdev configuration [ 7.095497] meson-drm d0100000.vpu: master bind failed: -22 [ 7.095879] meson-dw-hdmi: probe of c883a000.hdmi-tx failed with error -22 USB, DVFS does work OK Ethernet does work, but stutter/lack sometimes - its not every fluid working (SSH) WiFi is not populated on the C2 (checked again at the ordoid webpage) 0 Quote Link to post Share on other sites
Juanjo1024 0 Posted December 3, 2018 Share Posted December 3, 2018 Installed dev image and same as @guidol i have no HDMI, was going to do another flashing tonight but i guess im not the only one 0 Quote Link to post Share on other sites
TonyMac32 528 Posted December 3, 2018 Author Share Posted December 3, 2018 3 hours ago, Juanjo1024 said: i have no HDMI Yes, this is known issue. The only screen I have that comes up with HDMI without issue is a 7" RTD2660H device. Power it on without a monitor plugged in and plug it after, that may work until the issue is resolved. 6 hours ago, guidol said: Ethernet does work, but stutter/lack sometimes - its not every fluid working Hmmm, I did not see this, but I was going between 3 boards. Will check. 6 hours ago, guidol said: WiFi is not populated on the C2 Correct, the only one in the family we currently support with WiFi is the K2 0 Quote Link to post Share on other sites
guidol 260 Posted December 4, 2018 Share Posted December 4, 2018 10 hours ago, TonyMac32 said: Yes, this is known issue. The only screen I have that comes up with HDMI without issue is a 7" RTD2660H device. Power it on without a monitor plugged in and plug it after, that may work until the issue is resolved. I did read about the issue some time ago, therefore I didnt know if it would work at 4.19.y My HDMI/VGA-Monitor also doenst get a picture if I start the C2 and then later connect this monitor. SSH-stuttering is only sometimes..... a find / -name *e* does run without a stutter very quickly 0 Quote Link to post Share on other sites
TonyMac32 528 Posted December 6, 2018 Author Share Posted December 6, 2018 @Neil Armstrong New patchset rolled out, HDMI is still a problem, this occured when unplugging the monitor that was attached at boot: Spoiler [ 185.315428] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 [ 185.318605] Mem abort info: [ 185.321352] ESR = 0x96000004 [ 185.324337] Exception class = DABT (current EL), IL = 32 bits [ 185.330228] SET = 0, FnV = 0 [ 185.333253] EA = 0, S1PTW = 0 [ 185.336323] Data abort info: [ 185.339206] ISV = 0, ISS = 0x00000004 [ 185.343030] CM = 0, WnR = 0 [ 185.345926] user pgtable: 4k pages, 48-bit VAs, pgdp = 000000002dc85f55 [ 185.352487] [0000000000000020] pgd=0000000000000000 [ 185.357305] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 185.362805] Modules linked in: lz4hc lz4hc_compress snd_soc_hdmi_codec snd_soc_simple_card dw_hdmi_cec dw_hdmi_i2s_audio snd_soc_meson_i2s_dai snd_soc_meson_aiu_spdif_dma snd_soc_meson_aiu_i2s_dma snd_soc_simple_card_utils snd_soc_meson_spdif_dai snd_soc_core meson_vdec snd_pcm_dmaengine videobuf2_dma_contig snd_pcm videobuf2_memops snd_timer meson_rng v4l2_mem2mem snd meson_dw_hdmi zram rng_core zsmalloc videobuf2_v4l2 meson_drm soundcore dw_hdmi videobuf2_common drm_kms_helper videodev drm snd_soc_meson_audio_core ao_cec media drm_panel_orientation_quirks meson_canvas meson_ir cec meson_gxbb_wdt rc_core scpi_hwmon ip_tables x_tables [ 185.418648] CPU: 1 PID: 2785 Comm: Xorg Not tainted 4.19.7-meson64 #5.67 [ 185.425249] Hardware name: Libre Technology CC (DT) [ 185.430079] pstate: 40000005 (nZcv daif -PAN -UAO) [ 185.434867] pc : restore_fbdev_mode+0x18/0x1b0 [drm_kms_helper] [ 185.440717] lr : drm_fb_helper_restore_fbdev_mode_unlocked+0x70/0xe8 [drm_kms_helper] [ 185.448452] sp : ffff00000f16bcc0 [ 185.451725] x29: ffff00000f16bcc0 x28: ffff8000668d8000 [ 185.456987] x27: 0000000000000000 x26: 0000000000000000 [ 185.462248] x25: 0000000056000000 x24: ffff8000705ab8f8 [ 185.467510] x23: ffff000000b973a0 x22: ffff80006e856600 [ 185.472771] x21: 0000000000000000 x20: 0000000000000000 [ 185.478032] x19: ffff80006e856600 x18: 0000000000000000 [ 185.483293] x17: 0000000000000000 x16: 0000000000000000 [ 185.488554] x15: 0000000000000000 x14: 0000000000000000 [ 185.493816] x13: 0000000000000040 x12: 0000000000000228 [ 185.499077] x11: 0000000000000000 x10: 0000000000000000 [ 185.504338] x9 : ffff000008e69888 x8 : ffff000000b9d000 [ 185.509599] x7 : 0000000000000000 x6 : 0000000000000001 [ 185.514860] x5 : 0000000000000000 x4 : 0000000000000000 [ 185.520122] x3 : 0000000000000000 x2 : ffff8000668d8000 [ 185.525383] x1 : 0000000000000000 x0 : ffff80006e856600 [ 185.530647] Process Xorg (pid: 2785, stack limit = 0x0000000017f2a5e7) [ 185.537115] Call trace: [ 185.539556] restore_fbdev_mode+0x18/0x1b0 [drm_kms_helper] [ 185.545078] drm_fb_helper_restore_fbdev_mode_unlocked+0x70/0xe8 [drm_kms_helper] [ 185.552497] drm_fbdev_client_restore+0xc/0x18 [drm_kms_helper] [ 185.558421] drm_client_dev_restore+0x70/0xc8 [drm] [ 185.563229] drm_lastclose+0x58/0xd8 [drm] [ 185.567276] drm_release+0xe8/0x118 [drm] [ 185.571189] __fput+0x8c/0x1c0 [ 185.574203] ____fput+0xc/0x18 [ 185.577222] task_work_run+0x98/0xb8 [ 185.580759] do_notify_resume+0x124/0x128 [ 185.584725] work_pending+0x8/0x10 [ 185.588090] Code: f9000ff4 f90017f6 aa0003f6 f9402014 (f9401280) [ 185.594129] ---[ end trace 59a3ca1145f03b9e ]--- Message from syslogd@localhost at Dec 6 06:04:06 ... kernel:[ 185.357305] Internal error: Oops: 96000004 [#1] PREEMPT SMP Message from syslogd@localhost at Dec 6 06:04:06 ... kernel:[ 185.530647] Process Xorg (pid: 2785, stack limit = 0x0000000017f2a5e7) Message from syslogd@localhost at Dec 6 06:04:06 ... kernel:[ 185.588090] Code: f9000ff4 f90017f6 aa0003f6 f9402014 (f9401280) My 7" is still perfect, the hdmi/dvi adapter and the 4K Samsung are still issues. One strange note: Like before booting with no monitor then adding one works. However switching monitors results in a garbled display on the first plug, then a pull/replug it is fine. So Boot ----> plug in monitor ---> unplug, plug into 2nd monitor (*garbage ensues, no errors though*), unplug -----> replug ---> perfect. From low to high res you get only half the larger screen, on high to low res move it is completely corrupted. 0 Quote Link to post Share on other sites
Neil Armstrong 16 Posted December 6, 2018 Share Posted December 6, 2018 Hi @TonyMac32 I'm having a look at this. First, please apply these 2 fixes to remove the kernel warnings : https://github.com/freedesktop/drm-misc/commit/2bcd3ecab773f73211c45bb1430bb52ac641f271 https://github.com/freedesktop/drm-misc/commit/995b278e4723b26f8ebf0e7c119286d16c712747 (They will be backported to 4.19 in the next weeks) Can you try powering the monitor on an external power source, then power the board with the display already powered ? I have an issue with USB Displays, since the kernel enables the USB power very late, the monitor EDID is not available and the kernel fallsback automatically to 1024x768 resolution. This could explain why if you unplug/replug, it works. Powering the display *before* could solve this, the solution is to enable the 5V USB power from U-Boot. You can also try adding "usb start" in the boot script before starting the kernel. @guidolyour monitor seems weird ! Could you provide the EDID of the monitor ? Could you try this patch https://patchwork.freedesktop.org/patch/254756/ this should avoid the "*ERROR* Failed to set fbdev configuration" error ? 0 Quote Link to post Share on other sites
guidol 260 Posted December 6, 2018 Share Posted December 6, 2018 7 minutes ago, Neil Armstrong said: @guidolyour monitor seems weird ! Could you provide the EDID of the monitor ? With another HDMI-cable my monitor does work Here is the EDID from my monitor.... I had to apt install read-edid and then give the command get-edid|parse-edid Spoiler root@odroid-c2(192.168.6.117):~# get-edid|parse-edid This is read-edid version 3.0.2. Prepare for some fun. Attempting to use i2c interface No EDID on bus 0 1 potential busses found: 1 256-byte EDID successfully retrieved from i2c bus 1 Looks like i2c was successful. Have a good day. Checksum Correct Section "Monitor" Identifier "M19N4" ModelName "M19N4" VendorName "HSP" # Monitor Manufactured week 12 of 2008 # EDID version 1.3 # Digital Display DisplaySize 380 300 Gamma 2.20 Option "DPMS" "true" Horizsync 30-82 VertRefresh 50-75 # Maximum pixel clock is 140MHz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1280x960, 60Hz #Not giving standard mode: 1152x864, 75Hz #Extension block found. Parsing... Modeline "Mode 10" +hsync +vsync Modeline "Mode 0" +hsync +vsync Modeline "Mode 1" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace Modeline "Mode 2" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 3" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 4" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync Modeline "Mode 5" 27.027 1440 1478 1602 1716 480 484 487 525 -hsync -vsync interlace Modeline "Mode 6" 27.027 1440 1478 1602 1716 480 484 487 525 -hsync -vsync interlace Modeline "Mode 7" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace Modeline "Mode 8" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 9" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 11" +hsync +vsync interlace Modeline "Mode 12" -hsync -vsync Modeline "Mode 13" -hsync -vsync interlace Option "PreferredMode" "Mode 10" EndSection 0 Quote Link to post Share on other sites
Neil Armstrong 16 Posted December 6, 2018 Share Posted December 6, 2018 Oh yeah for the Ethernet, you should really take this fix https://patchwork.kernel.org/patch/10712159/ The IRQ type was wrong since the beginning... not it works correctly... 0 Quote Link to post Share on other sites
TonyMac32 528 Posted December 6, 2018 Author Share Posted December 6, 2018 6 hours ago, Neil Armstrong said: I have an issue with USB Displays Interesting, the only monitor I have that works from boot is a USB connected one... The monitors giving me trouble are both powered via their own main line supplies. Perhaps the issue is with the phy not being powered soon enough rather than with the monitor... If a display is plugged in on boot (other than my USB one), it does not recover, no matter what monitor or number of plug cycles are used. for the other, (note my HDMI knowledge is minimal, but from "the old days" of scanline displays), the phenomena I am seeing on unplug/replug *looks* like the vsync is not updating when you plug in the new display. So when a low res display is disconnected and a high res connected, the same number of vertical pixels are displayed and the rest of the screen is black. When going the other way, the horizontal over runs the vertical line and "wraps" causing an interlaced pattern. 3 hours ago, Neil Armstrong said: Oh yeah for the Ethernet, you should really take this Ah ok, I had seen it but hadn't looked closely. Thanks! 0 Quote Link to post Share on other sites
Neil Armstrong 16 Posted December 6, 2018 Share Posted December 6, 2018 @TonyMac32 weird stuff, could you dump the DRI driver status in /sys/kernel/debug/dri at each step ? same for EDID, EDID+status when freshly booted and non-working screen, and the same with it's working Thanks ! @guidol can you dump the output of read-edid in binary format ? the parse-edid gives Xorg format output, which is not the best :-p Neil 0 Quote Link to post Share on other sites
guidol 260 Posted December 6, 2018 Share Posted December 6, 2018 27 minutes ago, Neil Armstrong said: @guidol can you dump the output of read-edid in binary format ? the parse-edid gives Xorg format output, which is not the best :-p I did get-edid > guidol_edid.bin and put it in a .zip guidol_edid.zip 0 Quote Link to post Share on other sites
TonyMac32 528 Posted December 7, 2018 Author Share Posted December 7, 2018 @Neil Armstrong I'm not really sure how, but just adding the 2 patches (the IRQ for eth and max height/width) and my DVI monitor started on boot... I'll do some more testing and let you know. [update] it booted twice in a row, but it still has all of the bugs other than the boot one... 0 Quote Link to post Share on other sites
TonyMac32 528 Posted December 7, 2018 Author Share Posted December 7, 2018 acerEDID.bin samsungEDID.bin USB-EDID.bin Acer dri/status: Spoiler plane[32]: meson_primary_plane crtc=meson_crtc fb=38 allocated by = Xorg refcount=2 format=XR24 little-endian (0x34325258) modifier=0x0 size=1920x1080 layers: size[0]=1920x1080 pitch[0]=7680 offset[0]=0 obj[0]: name=0 refcount=3 start=00101fa8 size=8294400 imported=no crtc-pos=1920x1080+0+0 src-pos=1920.000000x1080.000000+0.000000+0.000000 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range plane[33]: meson_overlay_plane crtc=(null) fb=0 crtc-pos=0x0+0+0 src-pos=0.000000x0.000000+0.000000+0.000000 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range crtc[34]: meson_crtc enable=1 active=1 planes_changed=0 mode_changed=0 active_changed=0 connectors_changed=0 color_mgmt_changed=0 plane_mask=1 connector_mask=2 encoder_mask=2 mode: 0:"" 0 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x0 0x5 connector[28]: Composite-1 crtc=(null) connector[31]: HDMI-A-1 crtc=meson_crtc acer dri/framebuffer: Spoiler framebuffer[38]: allocated by = Xorg refcount=2 format=XR24 little-endian (0x34325258) modifier=0x0 size=1920x1080 layers: size[0]=1920x1080 pitch[0]=7680 offset[0]=0 obj[0]: name=0 refcount=3 start=00101fa8 size=8294400 imported=no framebuffer[52]: allocated by = [fbcon] refcount=1 format=XR24 little-endian (0x34325258) modifier=0x0 size=1920x3240 layers: size[0]=1920x3240 pitch[0]=7680 offset[0]=0 obj[0]: name=0 refcount=3 start=00100000 size=24883200 imported=no USB HDMI dri/state: Spoiler plane[32]: meson_primary_plane crtc=meson_crtc fb=38 allocated by = Xorg refcount=2 format=XR24 little-endian (0x34325258) modifier=0x0 size=800x480 layers: size[0]=800x480 pitch[0]=3200 offset[0]=0 obj[0]: name=0 refcount=3 start=00101bc6 size=1536000 imported=no crtc-pos=800x480+0+0 src-pos=800.000000x480.000000+0.000000+0.000000 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range plane[33]: meson_overlay_plane crtc=(null) fb=0 crtc-pos=0x0+0+0 src-pos=0.000000x0.000000+0.000000+0.000000 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range crtc[34]: meson_crtc enable=1 active=1 planes_changed=0 mode_changed=0 active_changed=0 connectors_changed=0 color_mgmt_changed=0 plane_mask=1 connector_mask=2 encoder_mask=2 mode: 0:"" 0 29570 800 816 896 992 480 481 484 497 0x0 0x6 connector[28]: Composite-1 crtc=(null) connector[31]: HDMI-A-1 crtc=meson_crtc USB dri/framebuffer: Spoiler framebuffer[38]: allocated by = Xorg refcount=2 format=XR24 little-endian (0x34325258) modifier=0x0 size=800x480 layers: size[0]=800x480 pitch[0]=3200 offset[0]=0 obj[0]: name=0 refcount=3 start=00101bc6 size=1536000 imported=no framebuffer[52]: allocated by = [fbcon] refcount=1 format=XR24 little-endian (0x34325258) modifier=0x0 size=1920x3240 layers: size[0]=1920x3240 pitch[0]=7680 offset[0]=0 obj[0]: name=0 refcount=3 start=00100000 size=24883200 imported=no 0 Quote Link to post Share on other sites
rino 4 Posted December 8, 2018 Share Posted December 8, 2018 Using kernel: Linux lepotato 4.19.7-meson64 #5.67.181207 SMP PREEMPT Fri Dec 7 10:25:31 CET 2018 aarch64 GNU/Linux HDMI it's ok on my PA248Q ASUS 1920x1200 monitor. Usability problems I can see: -slow windows resizing in XFCE -chromium windows not integrated in XFCE destop env (top right buttons missing) -no video acceleration in Chromium or mpv media player -too many flickering of mouse pointer on the desktop background. 0 Quote Link to post Share on other sites
Neil Armstrong 16 Posted December 8, 2018 Share Posted December 8, 2018 Yes this is normal since there is no HW OpenGL acceleration yet ! (But Lima is beginnning to be usable !) @TonyMac32i think I the last issue for your 4K display : drop the CONFIG_DRM_FBDEV_OVERALLOC=300 to CONFIG_DRM_FBDEV_OVERALLOC=100 this 300 value is only used for the libMali fbdev, otherwise it’s useless and a waste of memory ! 0 Quote Link to post Share on other sites
TonyMac32 528 Posted December 9, 2018 Author Share Posted December 9, 2018 @Neil Armstrong Well, let's say I start packaging Mali, would I need to set it back? The only reason I ask is that I haven't put it in there because I want to build the driver with the kernel rather than externally, and just haven't taken the time to do it properly. On another note, I have dead USB ports on C2 and K2, if the board is booted with nothing plugged in. It made me think of the dwc2 issues on the Rockchip RK3288's, where booting with nothing plugged in caused a buggy sleep state, but the solution for that issue did not resolve this one (checking to make sure it even translates properly). OK, first time I did it wrong, second time appears to do the trick, but I need more test time, no question. https://github.com/armbian/build/blob/master/patch/kernel/meson64-dev/general-dwc2-partial-powerdown-fix.patch 0 Quote Link to post Share on other sites
Neil Armstrong 16 Posted December 9, 2018 Share Posted December 9, 2018 @TonyMac32the overalloc is for the fbdev variant only, which won't work at all on 4.19 (needs a dirty quirk to enable it back which will land on 4.20 https://www.spinics.net/lists/dri-devel/msg191151.html), if you plan to use the X11, Wayland or GBM variant you should use the CONFIG_DRM_FBDEV_OVERALLOC=100 default config For USB, this patch https://github.com/chewitt/LibreELEC.tv/blob/amlogic/projects/Amlogic/patches/linux/linux-9999-dwc2.patch should solve your issue for the K2 and C2. 0 Quote Link to post Share on other sites
TonyMac32 528 Posted December 9, 2018 Author Share Posted December 9, 2018 6 hours ago, Neil Armstrong said: if you plan to use the X11, Wayland or GBM variant you should use the CONFIG_DRM_FBDEV_OVERALLOC=100 default config Awesome, will do. 0 Quote Link to post Share on other sites
Tommy21 1 Posted December 9, 2018 Share Posted December 9, 2018 I've seen a lot of changes are coming in kernel 4.21, will it be possible to use wayland in the near future? 0 Quote Link to post Share on other sites
Neil Armstrong 16 Posted December 12, 2018 Share Posted December 12, 2018 @Tommy21 No need to wait, it already works 1 Quote Link to post Share on other sites
Tommy21 1 Posted December 12, 2018 Share Posted December 12, 2018 [mention=3841]Tommy21[/mention] No need to wait, it already worksIs it possible to use it on existing Armbian/Amlogic boards images, or do we need to build image? 0 Quote Link to post Share on other sites
Neil Armstrong 16 Posted December 12, 2018 Share Posted December 12, 2018 @Tommy21You won't have OpenGL acceleration, but yes should be able with the actual images. With a Bionic ubuntu desktop image, you should be able to select wayland gnome at the login prompt. 0 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.