Posts by jernej

    I played a bit with various flags in DT but nothing helps to restore speed. I have a feeling that H6 mmc driver is not optimized but I have no idea about it. Since it works for you I won't spend much time on it for now. Anyway, PR for PineH64 eMMC support would be welcome. If you don't want to do it, I can take a shoot sometime in future.

    EDIT: So I did same speed on Android where I got ~130 MiB/s so definitely driver issue.

    ha, on Tanix TX6 I get without mmc-hs400-1_8v

    Code
    /dev/mmcblk1:
     HDIO_DRIVE_CMD(identify) failed: Invalid argument
     Timing buffered disk reads: 244 MB in  3.01 seconds =  81.15 MB/sec

    and with mmc-hs400-1_8v

    Code
    /dev/mmcblk1:
     HDIO_DRIVE_CMD(identify) failed: Invalid argument
     Timing buffered disk reads: 132 MB in  3.01 seconds =  43.92 MB/sec

    so this for some reason halves access read speed...

    roel No need to read markings, I got info that I need from Odroid page. In your case mmc-hs400-1_8v; would be more correct.

    Can you make read speed test with hdparm? I forgot exact command but I know you should make non-buffered test, otherwise read speed will be much too high.

    serafis Great job! That's really helpful. So it turns out there is (are) issue(s) with HDMI and/or clock configuration for particular resolution. It makes sense that could be a problem. Audio packets are sent in blanking intervals between two consecutive frames. If this timing is off then there could be also audio issues. Can you please provide output of edid-decode /sys/class/drm/card0-HDMI-A-1/edid? This should tell what timings are communicated by your TV and AVR. I just tested 1360x768p @ 60 Hz on my TV and everything seems to work fine. I suspect that my TV is pretty forgiving for non-optimal configurations.

    Regarding multi-channel configuration - I noticed that same format (iec958) is used also for non-passthrough (linear PCM) audio. This shouldn't be the case, so ALSA config needs some changes.

    I see you fixed it for the Tanix T6 with this patch:

    This is not a fix but workaround. Consequently, it was later removed when I found a proper solution for Tanix TX6.

    The LE patches are only patches for the dts of the Tanix TX6, does this mean if I apply these patches in the pineH64 dts, the board will boot from emmc? Probably it's a better fix that enables the HS DDR mode?

    Yes, same approach should work for PineH64 too, just make sure that you properly specify regulators. This was main issue with Tanix TX6.

    Sorry, I'm being unclear. Let me rephrase - most cheap H6 TV boxes have fixed CPU voltage. This means that most of the time CPU is powered with excessively high voltage which of course generates more heat. You can't do anything about it because this depends on the chip which is soldered on the board. Contrary to TV boxes, SBC with H6 have adjustable voltage regulator connected to CPU and that allows kernel to lower voltage when lower frequency is set and thus avoid higher temperatures. While SBCs seems unattractive at first glance (plain board, usually no remote nor power supply included), for similar or even higher price, they are most of the time better designed.

    But that is already off topic here. Please open new topic or ask in general topic such questions.

    Yeah, I saw such issues when there was a bug in display driver when using more than one plane. In this case video is one plane and GUI overlay another. For some reason overlay plane gets clipped to the visible size of video plane.

    Can you tell me more about your setup? What is your display resolution and refresh rate? What is the frame rate of the videos which can cause this issue? Board is OrangePi PC, right?

    I only have LG B8 TV with passthrough support for some formats (no AVR inbetween) where all works fine, so no, I have no idea what could be wrong. I'll do some more testing.

    Make sure you have selected correct HDMI output - one with the name of your AVR (or is it TV?) device.

    OrangePi 3 is reasonable choice, everything works great except ethernet may from time to time not come up at boot. But this may be fixed by ATF update I should do. This is actually the board I test more often.

    Yes, graphics is the same as on S905X3, but as I said, mesa is just now getting proper support for it. However, there are binary driver available but I always prefer mesa over them. In the past already happen that binary drivers weren't totally compatible with another SoC and SoC designer refused to release appropriate variant due to various reasons.

    My recommendation would be H6, at least from Allwinner. There is still a lot of potential to unlock while already mostly on feature parity with older ones. To be honest, I don't think you need more than 3 GiB of RAM. I'm still working with 2 GiB and even 1 GiB boards and I don't see any downside. Regarding hot cpu - most cheap H6 boxes are crap because they lack precise CPU voltage management. This tends to cause higher temperatures due to higher voltage used. Additionally, in the future, H6 will get its own LE kernel settings (currently shared with other 64-bit Allwinner SoCs), which will also allow lower temperatures (at least in theory).

    Ok, I'll prepare H6 update soon. BTW, H616 can't be supported at the moment. It's pretty different SoC and there is no documentation nor sources available for it. Also it's uses newer GPU which is just now getting support in mesa.