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.

Some comments (based on v7): a) The sdio_pwrdeq node is in the wrong place in the dts, it should be in the initial indented section, see https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi#L94-L99 - it is not a top-level node. b) I'll say again (third or fourth time now) .. the vendor binding MUST be submitted in its own patch first, THEN you submit the board binding separately in its own patch. THEN you submit the board dts in its own patch. Do not combine the vendor and board bindings into a single patch. c) You have added "Signed-off-by: Sean Young <sean@mess.org>" to the RC patch. Sean is the RC subsystem maintainer so he made a couple of comments. He is not an author of the patch and I see no claim of authorship in his comments. Comments are not substantial changes requiring a share of authorship so you are the single author and only your SOB is required. Sean will provide a Reviewed-By tag once he reviews it. NB: Searn normally he does a single review of all pending patches per kernel dev cycle (around rc-6 stage) to act/review them, so this patch will sit unanswered for a while - be patient - but you need to submit it to the correct mailing list first. d) The RC patch should be submitted separatedly and versioned separately from the board bindings/dts as this patch is (should be) submitted to a different mail-list list/subsystem with different maintainers (linux-media, Sean) from the Amlogic SOC list/subsystem (Neil/Kevin/Martin). The RC patches are now v2 or v3 patches. I don't see the latest patches on the linux-media list. NB: Note that linux-media maintainers use a different patchwork host https://patchwork.linuxtv.org/project/linux-media/list/ if you want to mark old patches superseded. e) Use ./scripts/get_maintainer.pl /path/to/your.patch to get the list of all people for the To/Cc fields when you submit. I personally use some aliases in ~/.gitconfig to avoid re-typing all the addresses out when I use git send, so I have git send-amlogic and git send-rc to make life simple.

The v5 series has no vendor binding. See here: 1. Add the "tmall" vendor binding: https://github.com/chewitt/linux/commit/35fd1261ccd8ef0fae50e8dde26f728685f80a44 2. Add the "magicbox-m16s" board binding: https://github.com/chewitt/linux/commit/907be915c59639ecb58b1504880ec0c59956cd3b 3. Add the board dts with the tmall,magicbox-m16s compatible: https://github.com/chewitt/linux/commit/d6a0784dfce8e704cecf5c6f7fe7d46d7642b81a You can do the vendor as "magicbox" and board as "m16s" if you prefer, but the number of patches and sequence should be the same. NB: As the purpose of the vendor binding is to get the true name of the manufacturer, they are often something a bit obscure, e.g. Beelink are actually "Shenzen AZW" so their binding is "azw" not "beelink" .. I couldn't find anything online about this box though - but only looking in English language sources, so if it was a Chinese market box I'm probably looking in the wrong language.

You must add the vendor binding first, then you can add the board binding, and then you can add the board dts with the board compatible (so you need three separate patches). You can also combine the RC bindings and driver into a single patch; it's acceptable to the subsystem maintainer and makes his review easier.

@ning please see the 4x commits in this branch https://github.com/chewitt/linux/commits/amlogic-5.19.y for an example of how the patches for a new board should be presented to LKML. e.g. First add vendor binding, then board binding, then board dts. The RC keymap goes to a different list and can be done separately. As long as the Amlogic maintainers can see that the keymap has been sent to the media mailing-list at the same time they are normally fine to accept the ir-keymap node in the board dts. NB: The maintainers are not fans of minimal dts files being added, followed by lots of patches to enable individual hardware features. It's not technically a "wrong" approach, but for a simple simple TV Box it is better "etiquette" to finalise the dts first (with lots of testing etc.) *then* send the finished patches upstream. The 'box' image here: https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-box.img.gz includes the dts from my kernel repo. If you would like to test boot it (set the dtb name in uEnv.ini) and share the dmesg log it would help me/us to see what's working (or not) and what adjustments might be required. Most S912 boxes are clones of the Q200/Q201 reference designs so the dts should be quite simple to figure out. I guessed at the Marvell WiFi/BT pieces: WiFi might work, but BT will probably need some changes.

I have recently upstreamed a device-tree for the GT1-Ultimate, see: https://patchwork.kernel.org/project/linux-amlogic/patch/20220707101423.90106-1-jbrunet@baylibre.com/. AFAIK the box only shipped with a Broadcom SDIO module and the earlier (non-ultimate) GT1 box has the QCA9377 inside. If I can get confirmation (and dmesg log output) from a non-ultimate box with QCA9377 booting the following LE image I will send the non-ultimate GT1 dts upstream too: https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-box.img.gz - set the non-ultimate GT1 dtb name in uEnv.ini before booting. I've also added the u-boot signing FIPs here: https://github.com/LibreELEC/amlogic-boot-fip/tree/master/beelink-gt1 - It's been tested with a genuine GT1-Ultimate (there are some fakes in circulation) but the Beelink devs claim the same u-boot sources are used with both versions of the box. There's a pre-built u-boot 2022.07 binary here: https://chewitt.libreelec.tv/testing/u-boot/u-boot.bin.sd.bin-beelink-gt1 that can be used for SD/eMMC booting.

@mfizz This is a signed u-boot.bin.sd.bin file (u-boot 2022.07) for WP2 that can be written to SD or eMMC in the normal way (https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Amlogic/bootloader/mkimage#L8-L9). It allows u-boot and MBR structures to coexist so you can partition emmc as you like for an Armbian install: https://chewitt.libreelec.tv/testing/u-boot/u-boot.bin.sd.bin-wetek-play2 NB: The WP2 boot FIPs for signing are here (extracted from WeTek u-boot sources): https://github.com/LibreELEC/amlogic-boot-fip/tree/master/wetek-play2

That's interesting (some clever work) but a slightly different topic. You're manipulating the Amlogic (2015.01 based) u-boot and the custom partition layout to suit Armbian/Linux. It looks rather fiddly to execute but suits TV box devices where you have no access to the vendor customised u-boot sources. I'm creating new distro images that boot using upstream u-boot (2022.07) from SD or eMMC and clean-install the OS with standard mbr/msdos partitions. This is cleaner, but needs access to the vendor u-boot sources to build/extract the FIPs and customised software bits needed for signing the modern u-boot binaries. NB: I'd like to see an effort to script or create tools that deconstruct the contents of vendor images to extract the acs.bin/bl2.bin/bl301.bin files which are tweaked for the device (esp. acs.bin which has the often low-bin RAM timings). These could then be used with other common files (bl21.bin/bl30.bin/etc.) to create a FIP package for signing modern u-boot. Спасибо, что поделились!

See commits here: https://github.com/chewitt/amlogic-boot-fip/commits/gxbb-sd-emmc which is based on the original detective work done by @Kwiboo here https://github.com/Kwiboo/u-boot/commit/6d0a17632922077a2e64b13ae1a6bdf0024b718f .. waaaay back in 2016, so the solution has been sitting under our noses all this time The one difference from his instructions is that I don't use the same 'fusing' instructions, I use the standard LE ones https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Amlogic/bootloader/mkimage#L8-L9 Here's the u-boot log https://pastebin.com/raw/pVSHMueQ and dmesg https://pastebin.com/raw/n5E3Rq96 showing emmc boot on the WP2.

I'm posting here in the hope someone with a NanoPi-K2 board can test-boot the following LibreELEC image from an eMMC module and SD (the same image should boot both). If it does work the long-running mystery of how to combine various bits of upstream u-boot (2022.07) with Amlogic signed firmware and MBR structures is solved. I'm able to boot an S905 set-top box (WeTek Play2) so I'm fairly confident it should work. Here's the test image: https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-nanopi-k2.img.gz

https://patchwork.kernel.org/project/linux-amlogic/patch/20201030180057.23886-1-christianshewitt@gmail.com/ ^ tested by the maintainers .. enjoy :)