Jump to content

zamrih

Members
  • Posts

    2
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hello balbes150, The 20170424 image 4.11 Test does boot but unfortunately there was issues with both wired and wireless network. The provided meson-gxbb-p200-lan.dtb didn't change things as I believe from the sources, the corresponding dts file was still using the "rgmii" ( gigabit ) mode whereas "mii" is the 100M one specific to the p200 board variation. &ethmac { status = "okay"; pinctrl-0 = <&eth_rgmii_pins>; pinctrl-names = "default"; phy-handle = <&eth_phy0>; phy-mode = "rgmii"; snps,reset-gpio = <&gpio GPIOZ_14 0>; snps,reset-delays-us = <0 10000 1000000>; snps,reset-active-low; amlogic,tx-delay-ns = <2>; mdio { compatible = "snps,dwmac-mdio"; #address-cells = <1>; #size-cells = <0>; eth_phy0: ethernet-phy@0 { reg = <0>; eee-broken-1000t; }; }; }; The "amlogic,tx-delay-ns" part as well as eee-broken-1000t are not necessary from what I could find as they're specific to gigabit cards. Combining the previous patch and ethmac section from p201 board dts file results in having this p200-100m dts ethmac : &ethmac { status = "okay"; pinctrl-0 = <&eth_rmii_pins>; pinctrl-names = "default"; phy-mode = "rmii"; mc_val = <0x1800>; snps,reset-gpio = <&gpio GPIOZ_14 0>; snps,reset-delays-us = <0 10000 1000000>; snps,reset-active-low; }; The only unconfirmed part is the "mac_val" key value pair. According to this : https://patchwork.kernel.org/patch/9198613/ One can understand that it's how the mac address is fetched from the device tree but I am especially having trouble with that exact part. The mac address is randomized after each reboot ( possibly after each time the stmmac module is added as from the kernel module source, it is if it's invalid : http://lxr.free-electrons.com/source/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#L1554 ). root@box:~# dmesg | grep mac [ 0.000000] Kernel command line: root=LABEL=ROOTFS rootflags=data=writeback rw console=ttyAML0,115200n8 console=tty0 no_console_suspend consoleblank=0 fsck.repair=yes net.ifnames=0 mac=XX:XX:XX:XX:XX:XX [ 3.262237] meson8b-dwmac c9410000.ethernet: PTP uses main clock [ 3.262621] meson8b-dwmac c9410000.ethernet: no reset control found [ 3.269442] stmmac - user ID: 0x11, Synopsys ID: 0x37 [ 3.275580] meson8b-dwmac c9410000.ethernet: Ring mode enabled [ 3.279729] meson8b-dwmac c9410000.ethernet: DMA HW capability register supported [ 3.293318] meson8b-dwmac c9410000.ethernet: Normal descriptors [ 3.299267] meson8b-dwmac c9410000.ethernet: RX Checksum Offload Engine supported [ 3.306571] meson8b-dwmac c9410000.ethernet: COE Type 2 [ 3.311740] meson8b-dwmac c9410000.ethernet: TX Checksum insertion supported [ 3.318692] meson8b-dwmac c9410000.ethernet: Wake-Up On Lan supported [ 3.325078] meson8b-dwmac c9410000.ethernet: Enable RX Mitigation via HW Watchdog Timer [ 3.342201] libphy: stmmac: probed [ 3.342248] meson8b-dwmac c9410000.ethernet (unnamed net_device) (uninitialized): PHY ID 02430c54 at 0 IRQ POLL (stmmac-0:00) active [ 12.603340] meson8b-dwmac c9410000.ethernet eth0: device MAC address 16:35:12:93:bd:5f [ 12.603757] Generic PHY stmmac-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=stmmac-0:00, irq=-1) [ 12.704628] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW [ 13.733161] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 15.005853] Generic PHY stmmac-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=stmmac-0:00, irq=-1) [ 15.104644] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW [ 17.157141] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx It looks however like it's correctly fetched with or without the mc_val property at the u-boot level when checking the kernel boot command line ( from the internal memory I presume ... read that on one post of yours ). root@box:~# cat /proc/cmdline root=LABEL=ROOTFS rootflags=data=writeback rw console=ttyAML0,115200n8 console=tty0 no_console_suspend consoleblank=0 fsck.repair=yes net.ifnames=0 mac=XX:XX:XX:XX:XX:XX As of the wifi, the 8189es module from amlogic ( "drivers/amlogic/wifi/rtl8192ES/" ) was the one working on the 3.14 kernel. I don't know which module should work with the 4.11 ( 4.10+ ? ) kernel but it looks like "rtlwifi" set of modules was not compiled. I did compile those modules alone but I can't find which one to use or if rtlwifi is at all what should be used ( no 8192es but 8192SE and 8192CU ). 4.11 : CONFIG_RTL8192CE=m CONFIG_RTL8192SE=m CONFIG_RTL8192DE=m CONFIG_RTL8192EE=m CONFIG_RTL8192CU=m CONFIG_RTL8192C_COMMON=m CONFIG_RTL8192U=m CONFIG_RTL8192E=m 3.14 : CONFIG_RTL8192EU=m CONFIG_RTL8192CU=m CONFIG_RTL8192DU=m CONFIG_RTL8192C_COMMON=m Here are the dts files I used for reference : arch/arm64/boot/dts/amlogic/meson-gxbb-p20x-2g.dtsi https://pastebin.com/5Emm8RMm arch/arm64/boot/dts/amlogic/meson-gxbb-p200-2g.dts https://pastebin.com/V1U0PFJL arch/arm64/boot/dts/amlogic/meson-gxbb-p200-2g-100m.dts https://pastebin.com/5UDcS7HY There's an extra dtsi file specifically for the 2g ram variation as the meson-gxbb-p20x.dtsi hard code 1g ram only. On a side note, don't how to reproduce the issue, but I noticed a hissing sound when plugging the box a tv via hdmi. Possibly when the box did boot already and plugging it afterwards to a tv ... One last thing about kernel compilation. It would be hugely helpful for testing and for upgrading as well to be able to build deb packages that one and everyone could install to test. You wouldn't need to cook new images for kernel testing that way. Try to look for this : make -j4 deb-pkg ( or make -j4 Image dtbs modules deb-pkg ) in the set_make script The tricky part would surely cooking the correct initrd and uInitrd files.
  2. Hello @balbes150 Great work with these Amlogic images. I've been using one of the 5.26 server flavour ones you published with docker on it ( the new docker-ce from their xenial repo ) with great success ( overlay fs ). I would have a little request if you don't mind. Could you include these patches for various device trees from kszaq ( the maintainer of the libreelec image for amlogic ) : https://github.com/kszaq/s905-device-trees The patches are made against the 3.14 kernel tree used by libreelec amlogic images. I am actually more interested in the "gxbb_p200_2G_100M_RealtekWiFi.patch" patch. It's specific to a S905 board with 2G RAM, non gigabit ethernet, realtek wifi chip and without bluetooth. WiFi was somehow working when using the the gxbb_p200_2G dtb but ethernet wasn't at all. I have successfully adapted it to gxbb_p200_2G.dts from a previous git pull of your amlogic kernel repo and ethernet/wifi is 100% functional : https://pastebin.com/GkB6aa07 https://pastebin.com/zFe10drB But since you recently switched to the 4.10/4.11/4.12 kernels, I wouldn't know if the mainline kernel does take into account these specific variations of the p200 amlogic boards ( 100M ethernet + realtek wifi ). I gave it a go a while back with the 4.10 kernel but although the compilation was successful, I couldn't boot it and couldn't figure out what was going wrong without UART console ... Thanks again for the great work!
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines