1 1
TonyMac32

Le Potato / C2 / K2 4.19 LTS testing thread

Recommended Posts

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.  :lol:

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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.  

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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.  

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
16 minutes ago, Igor said:

I looked (quickly) into and its working for me OOB :) Don't understand what is wrong? How to reproduce?

:blink:

 

[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? 

 

 

Share this post


Link to post
Share on other sites

@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) :)

 

 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 :)

Hannspree_Basketball_HDMI_VGA_Monitor_19Zoll.jpg

Share this post


Link to post
Share on other sites

@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.

 

 

Share this post


Link to post
Share on other sites

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 ?

 

Share this post


Link to post
Share on other sites
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
 

 

Share this post


Link to post
Share on other sites
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...  :lol:

 

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!

 

 

 

 

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

@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...

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

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.

 

 

 

Share this post


Link to post
Share on other sites

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 !

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

@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. 

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
[mention=3841]Tommy21[/mention] No need to wait, it already works

Is it possible to use it on existing Armbian/Amlogic boards images, or do we need to build image?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
1 1