chewitt

@Sosie It took me a while to test my current branch(es) but I see no boot issue on the M5 that I have: https://pastebin.com/raw/sT3GiLa3 Note that all I ever do is gunzip the image and dd directly to an SD card. I do zero manipulation of anything beyond occasionally forcing SSH on via extlinux.conf

I deleted the 10.95.1 image. There is a newer one in the same folder. Use initiative!

cd /storage/.update wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.95.1.tar reboot Hi, please update and then run "pastekodi" (and share URL) again. I've done something which might get Ethernet working?

cd /storage/.update wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.95.1.tar reboot ^ Update again please. I've added/enabled some additional Ethernet PHY drivers in the kernel. Do "pastekodi" afterwards. Thanks.

cd /storage/.update wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.95.1.tar reboot @Dimm500 please run those ^ commands and then run "pastekodi" and share the log again once the update completes. Ethernet fails to probe PHY address 0, so I've tweaked the device-tree to probe address 1 which is occasionally used by some boxes. also run "mdio" and it should list an MDIO entry for "stmmac-X" .. if yes, please run "mdio stmmac* | paste" and share that URL too please.

@Dimm500 Boot log looks okay apart from Ethernet not working (it's probed but fails). Does this box have 10/100 or Gigabit Ethernet? Can you share some high-res pics of the PCB (to see the Ethernet PHY chip markings)? WiFi and BT are both probed working so the device-tree looks correct for that part. Did WiFi/BT work with the default firmwares embedded in the LE image? - or not? - I'm unsure if "Now I used firmware from Slimbox" refers to WiFi/BT firmware files or a complete Android ROM image.

According to the Beelink developers the GT1-Ultimate shipped with a Broadcom WiFi module, while the earlier GT1 (non-ultimate, but looks identical) box shipped with a QCA9377 module. So either you have a non-ultimate box, or a fake Ultimate box (there are fakes around). https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.95.0-box.img.gz ^ This image includes a "meson-gxm-gt1.dtb" which should work with QCA9377 modules. I've been waiting for someone to show up and test it. So please install, SSH into the box, and share the URL generated by "pastekodi" so I can see the boot log. If WiFi and BT are working I will send the device-tree upstream to the kernel. If they aren't .. we can see the errors.

See https://github.com/chewitt/linux/commit/aee6af1b7f123920a3f43afcdb5832c335df909c for a workaround (both patch and boot params alternative). I'll ask Marting to nag the USB list for a response again, but we already did this about four times and nobody is responding.

Yes, upstreaming is all about timing and the process is deliberately not quick, to avoid mistakes. Anything you submit now will be for Linux v5.22 as the content for Linux v5.21 is already fixed and queued waiting for v5.20 to be released and the v5.21 merge window to open. Only fixes are handled quickly, so there's no rush

Not needed. It's your board and you're doing all the real work. I'm just helping with minor formating ... but thanks

Yes, that's correct. I have created board changes in this branch: https://github.com/chewitt/linux/commits/m16s-board and the RC changes are in this branch: https://github.com/chewitt/linux/commits/m16s-rc I created two branches because patches should be generated against the 'next' version of the subsystem you are submitting to. For board patches this is the v5.20/arm64-dt branch here: https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git and for the RC patches this is the master branch of https://git.linuxtv.org/media_tree.git I normally combine RC bindings and driver changes into a single patch. This is technically wrong (bindings should be separate) but as the binding and driver will be accepted by the same maintainer (Sean) through the same tree (Linux Media) combining makes review easier and in the past, nobody has complained about me doing this. However, as you already submitted bindings/driver in two patches I kept them as two patches for continuity. I made minor changes to the driver to move the inline comment to the header. I would not ask for Sean to Signoff again as this is a minor cosmetic change - I would simply make a note below the --- in the patch. I also revised the subject for the binding to match historic submissions .. "dt-bindings: rc: description" appears to be for structural changes to the RC bindings file, and "media: dt-bindings: rc: description" is used for adding new remotes to the bindings file. it's confusing I added the WiFi changes with some /* commented */ items - it's not clear to me if these are optional/required? ** !!! DO NOT (RE)SUBMIT !!! ** Amlogic maintainers will not merge new board patches for Linux 5.21 until approximately Linux 5.20-rc5/rc6 timeframe (in 2.5 months time) so there is lots of time to investigate the board and get more things working (LEDs, Keys, etc.) before submitting the next series. The RC patches can be resent earlier. For now, keep working on the board changes. We can discuss how and where to send the board/rc patches in future posts!

Most WiFi/BT chips are available in two variants; one for SDIO (with BT as a serial/uart device) and one for USB. I guarantee the box is not SDIO/USB on the same chip. All other GXL/GXM boxes are using serial BT devices on GPIOX_17 so the box is based on the Amlogic reference design (like all GXL/GXM Android boxes) and we just need to figure out the correct way to represent this in device-tree. Please share the Android dtb file - if you have it.

WiFi is an SDIO device, but BT is serial (UART) - and the GPIOX_17 is the same as other GXL/GXM devices. Does this work? (replacing the sd_emmc_a node) /* This is connected to the Bluetooth module: */ &uart_A { status = "okay"; pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>; pinctrl-names = "default"; uart-has-rtscts; bluetooth { compatible = "marvell,sd8897-bt"; reg = <2>; shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>; }; };

Using the GXBB 'WeTek Hub' as an example: This is the top (indented) section: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts#L12-L50 This is the main 'body' of the dts: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts#L51-L58 This is the default sdio_pwrseq node (inherited from include): https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi#L94-L99 - it is in the top/indented section. So if you add the node to your board dts (to override a property) the node should be in the same top/indented section, not the 'body' area. The device-tree file can only describe hardware that has driver support. If you add nodes for not-working LED items or WiFi the patch will be rejected. Once the required drivers are added to the kernel or fixed, or GPIO configs are figured out, then you can send a patch to add those nodes/items. NB: It is technically wrong to add the ir-node referencing an RC driver that does not exist (yet) in the kernel .. but nobody cares about IR remotes so that will be allowed I will push the RC driver and board dts patches to branches in my repo .. I will share links when done.

It's normal Everyone makes "etiquette" mistakes with first submissions and "learns the hard way" (me too). I can help you two ways (choose one): a) Push your patches to a GitHub repo - then I can review them to point out the mistakes and offer suggestions or corrections. b) I can replicate the patches and fixup the mistakes - then you can cherry-pick the patches and resubmit them.