Posts by koenkooi

    There you go: 2016-08-03-devel

    I will compare with your tree later to see what might be wrong. I am aware of ttyAMA in cmdline - but we need to have tty0 working.

    Thanks! I'm merging in your changes and testing the intermediate steps. Looking at the diff, the only thing that stands out is CONFIG_CMDLINE in the kernel, testing will show if that's the culprit. First build will be ready in an hour or so, hopefully some usefull test results at the end of the day!


    S905Xers, please test this build for booting issues: LibreELEC-S905.aarch64-7.0-devel-20160830160706-r23311-g51fe9ae.img.gz

    3 consecutive boots from uSD: can't mount mmcblk0p1
    2 consecutive boots from USB: can't mount LABEL=boot
    [hr]


    S905Xers, please test this build for booting issues: LibreELEC-S905.aarch64-7.0-devel-20160830160706-r23311-g51fe9ae.img.gz

    Could you upload a 'git diff' as well? I'm curious to see what the differences are between my local build based on Pulsars diff and some extra changes, which boots and yours. I've upload all my changes to my github fork.

    I'm having trouble with 4k video playback. My setup: m8s2 with pulsar build on eMMC -> onkyo receiver -> samsung 1080p TV. For every fps in the source material (23.976, 30 and 60Hz) it switches to 1080p60. 1080p material plays without any problems and switches refreshrate without any issues.

    I'm seeing some suspicious stuff in dmesg:

    Code
    [ 209.584836@2] codec:H264_4K2K: decinfo: 3840x2160 rate=3200
    [ 209.585240@2] codec:get_decoder_firmware_data vh264_4k2k_mc_single for format 10 failed!
    [ 209.585269@2] codec:
    [ 209.585269@2] amvdec_h264_4k2k init failed.

    Full dmesg kodi.log

    I double checked, and I have the update dtb with a larger fb memory:

    Code
    m8s:~ # od -h /proc/device-tree/reserved-memory/linux,meson-fb/size -h0000000 0000 0000 4804 00000000010

    Anything I can try to debug this further? I tried big buck bunny 2160p30, 2160p60 and 23.976 internet content, all h264.

    internal NAND flash (dev/system, /dev/data), eMMC would be SD Card, right?

    No, eMMC is chip on the board that is hooked up to the second MMC controller on the SoC. The 'e' stands for 'embedded'. Have a look at dmesg:

    Code
    m8s:~ # dmesg | grep -i mmcblk[    3.651653@3] mmcblk0: sd:b368 USD   3.75 GiB [    3.770124@1]  mmcblk0: p1 p2[    4.123791@0] mmcblk1: emmc:0001 NCard  7.21 GiB [    4.123918@0] mmcblk1boot0: emmc:0001 NCard  partition 1 4.00 MiB[    4.124046@0] mmcblk1boot1: emmc:0001 NCard  partition 2 4.00 MiB[    4.124162@0] mmcblk1rpmb: emmc:0001 NCard  partition 3 4.00 MiB[    4.193833@0]  mmcblk1: unknown partition table[    4.194948@0] [mmcblk1p01]           bootloader  offset 0x000000000000, size 0x000000400000 [    4.195293@0] [mmcblk1p02]             reserved  offset 0x000002400000, size 0x000004000000 [    4.195466@0] [mmcblk1p03]                cache  offset 0x000006c00000, size 0x000020000000 [    4.195622@0] [mmcblk1p04]                  env  offset 0x000027400000, size 0x000000800000 [    4.195771@0] [mmcblk1p05]                 logo  offset 0x000028400000, size 0x000002000000 [    4.195936@0] [mmcblk1p06]             recovery  offset 0x00002ac00000, size 0x000002000000 [    4.196089@0] [mmcblk1p07]                  rsv  offset 0x00002d400000, size 0x000000800000 [    4.196251@0] [mmcblk1p08]                  tee  offset 0x00002e400000, size 0x000000800000 [    4.196414@0] [mmcblk1p09]                crypt  offset 0x00002f400000, size 0x000002000000 [    4.196571@0] [mmcblk1p10]                 misc  offset 0x000031c00000, size 0x000002000000 [    4.196826@0] [mmcblk1p11]            instaboot  offset 0x000034400000, size 0x000020000000 [    4.197006@0] [mmcblk1p12]                 boot  offset 0x000054c00000, size 0x000002000000 [    4.197165@0] [mmcblk1p13]               system  offset 0x000057400000, size 0x000040000000 [    4.197320@0] [mmcblk1p14]                 data  offset 0x000097c00000, size 0x000136500000

    The microSD card in the slot is 4GB, the eMMC 8GB. I suspect /dev/system and /dev/data are android-isms that are just link to paritition 13 and 14 on the emmc.

    Of course both the microSD card and eMMC are created using NAND flash, but in general saying 'NAND flash' means using it without a translation layer through /dev/mtd*

    I am fighting NAND flash on a different board today and wondered if I needed go through the same frustrating experience with the s905x box :/

    EDIT: dmesg with linebreaks


    ... and here it is:

    index - powered by h5ai v0.29.0 (https://larsjung.de/h5ai/)

    thanks kszaq & koenkooi

    Lets hope kszaq comes up with an idea how to use the same set of build options / patches etc for S905 and S905X. Diff against the "official" 006 branch: eUib - so there are mainly some additions and serial console changes to the linux kernel. Other changes are either cosmetics or not relevant for non-debug releases.

    Please note that this is an experimental build and not well tested.

    I integrated your diff in my build and now usb and CEC work!

    dmesg: aDJh

    Works:

    • ethernet
    • wifi
    • GUI
    • h264 playback
    • switching to 1080p/24
    • dolby atmos passthrough
    • IR remote


    Doesn't work:

    • CEC
    • USB


    [hr]
    For people wanting to try it: Test image
    Replacing kernel.img and fixing up its md5 in the .006 build kszaq provides also works: kernel.img

    I recommend using kszaqs images and replacing the kernel.img, because only changes one thing instead of an unknown number of other things.

    I've finally received my m8sII and located the serial pads on it. It's the four pins are, starting with the square pad: GND, TX, RX, unknown. I've managed to dump the dtb in u-boot: gUUjand compared sections of it by hand to arch/arm64/boot/dts/amlogic/gxl_p212_2g.dts; so far they look the same, apart from the allocated framebuffer memory.

    I've tried SD boot as well as USB boot and get the same errors as mentioned earlier in the thread. I've not made any headway debugging this further since I don't have an LE build environment set up yet. For the future builds it would be nice to:

    • Set console=tty0 console=ttyS0,115200 to get the ramdisk output on both hdmi and serial
    • Increase the kernel loglevel for serial (I suspect 'quiet' is in the cmdline), all I get is hastebin


    Due to point 1. and 2. I can't say if mmblk0 is eMMC or not working at all. USB seems to be non-functional, keyboard LEDs don't light up and the 'BOOT' partlabel can't be found.
    [hr]


    I've finally received my m8sII and located the serial pads on it. It's the four pins are, starting with the square pad: GND, TX, RX, unknown. I've managed to dump the dtb in u-boot: gUUjand compared sections of it by hand to arch/arm64/boot/dts/amlogic/gxl_p212_2g.dts; so far they look the same, apart from the allocated framebuffer memory.

    I've tried SD boot as well as USB boot and get the same errors as mentioned earlier in the thread. I've not made any headway debugging this further since I don't have an LE build environment set up yet. For the future builds it would be nice to:

    • Set console=tty0 console=ttyS0,115200 to get the ramdisk output on both hdmi and serial
    • Increase the kernel loglevel for serial (I suspect 'quiet' is in the cmdline), all I get is hastebin


    Due to point 1. and 2. I can't say if mmblk0 is eMMC or not working at all. USB seems to be non-functional, keyboard LEDs don't light up and the 'BOOT' partlabel can't be found.

    Some progress, I replace only the kernel with one that has a differentCONFIG_CMDLINE: NhJe


    U-boot is not needed, this is handled by your manufacturer and my LE builds do not replace it. I guess it would be enough to provide an upadted kernel and you will probably see it in the next build. Also, I don't think that gxl is S905X, it's a slightly updated gxbb.

    That would also be nice.

    I was looking at this patch and the work the baylibre folks are doing to get amlogic support into mainline and they consistently refer to s905x as gxl. Having worked for a silicon vendor myself I can say: codenames change, a lot. So what ends up shipping in the tv box labeled 's905x' (updated gxbb) might not be the same as the 's905x' (gxl) on the evaluation board from amlogic. Anyway, we'll find out when I get my box to work.
    To hopefully save some work, can you enable the gxl bits in the updated kernel anyway?

    As for shipping an s905x box to the LE team, I'll happily do that provided the one I bought doesn't go up in flames at first boot, I don't trust cheap electronics. Getting the house of an LE dev burned down wouldn't help with this port ;)

    Due to the combination of having ordered an s905x box instead of a s905 one and having a few weeks off from work, I was wondering what is needed to get s905x supported.

    I've had a quick look at the latest amlogic kernel tarball and that seems to have s90x (aka 'gxl') support:

    Code
    koen@beast:/build/pkg/amlogic/arm-src-kernel-2016-05-04-bd1ff1c1cd$ grep mesongxl -irn ../drivers/amlogic/pinctrl/pinctrl_gxl.c:265:static struct meson_bank mesongxl_banks[] = {./drivers/amlogic/pinctrl/pinctrl_gxl.c:284:static struct meson_bank mesongxl_ao_banks[] = {./drivers/amlogic/pinctrl/pinctrl_gxl.c:291:static struct meson_domain_data mesongxl_domain_data[] = {./drivers/amlogic/pinctrl/pinctrl_gxl.c:294:            .banks          = mesongxl_banks,./drivers/amlogic/pinctrl/pinctrl_gxl.c:295:            .num_banks      = ARRAY_SIZE(mesongxl_banks),./drivers/amlogic/pinctrl/pinctrl_gxl.c:301:            .banks          = mesongxl_ao_banks,./drivers/amlogic/pinctrl/pinctrl_gxl.c:302:            .num_banks      = ARRAY_SIZE(mesongxl_ao_banks),./drivers/amlogic/pinctrl/pinctrl_gxl.c:583:    .domain_data    = mesongxl_domain_data,./drivers/amlogic/pinctrl/pinctrl_gxl.c:584:    .num_domains    = ARRAY_SIZE(mesongxl_domain_data),./arch/arm64/boot/dts/amlogic/gxl_pxp.dts:25:#include "mesongxl.dtsi"./arch/arm64/boot/dts/amlogic/gxl_p212.dts:25:#include "mesongxl.dtsi"./arch/arm64/boot/dts/amlogic/gxl_skt.dts:25:#include "mesongxl.dtsi"./arch/arm64/boot/dts/amlogic/mesongxl.dtsi:2: * arch/arm64/boot/dts/amlogic/mesongxl.dtsi

    Sadly this is a tarball without git history, so comparing it against kszaqs tree will be tedious. If someone knows where a public git tree of that is located, please let me know.

    Looking at the dtsi, the pin, clock and USB controllers are different from the s905:

    Code
    koen@beast:/build/pkg/amlogic/arm-src-kernel-2016-05-04-bd1ff1c1cd$ grep -irn -- -gxl  ../drivers/usb/phy/phy-aml-new-usb3.c:2: * phy-aml-gxl-usb3.c./drivers/usb/phy/phy-aml-new-usb3.c:17:#include <linux/amlogic/usb-gxl.h>./drivers/usb/phy/phy-aml-new-usb.c:13:#include <linux/amlogic/usb-gxl.h>./drivers/usb/phy/phy-aml-new-usb2.c:2:phy-aml-gxl-usb2.c./drivers/usb/phy/phy-aml-new-usb2.c:17:#include <linux/amlogic/usb-gxl.h>./drivers/usb/phy/phy-aml-new-usb.h:6:#include <linux/amlogic/usb-gxl.h>./drivers/amlogic/pinctrl/pinctrl_gxl.c:592:            .compatible = "amlogic, pinmux-gxl",./drivers/amlogic/pinctrl/pinctrl_gxl.c:609:            .name = "pinmux-gxl",./drivers/amlogic/amports/jpegenc.h:8:#define JPEGENC_DEVINFO_GXL "AML-GXL"./drivers/amlogic/amports/encoder.h:34:#define AMVENC_DEVINFO_GXL "AML-GXL"./drivers/amlogic/clk/Makefile:9:                                  clk-gxbb.o clk-gxtvbb.o clk-gxl.o \./drivers/amlogic/clk/clk-gxl.c:2: * drivers/amlogic/clk/clk-gxl.c./arch/arm64/boot/dts/amlogic/gxl_pxp.dts:785:          compatible = "amlogic, aml-gxl-usb2";./arch/arm64/boot/dts/amlogic/gxl_pxp.dts:792:          compatible = "amlogic, aml-gxl-usb3";./arch/arm64/boot/dts/amlogic/mesongxl.dtsi:183:                compatible = "amlogic, pinmux-gxl";

    Once my m8sII arrives I can actually try to test the kernel on real hardware. So apart from kernel and u-boot work, what is needed to get s905x supported in LE? And more imporantly, is someone already working on that? The post in this forum imply that noone is working on it yet, but if someone is, please speak up :)