Jump to content

chewitt

Members
  • Posts

    35
  • Joined

  • Last visited

Everything posted by chewitt

  1. 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.
  2. 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
  3. Not needed. It's your board and you're doing all the real work. I'm just helping with minor formating ... but thanks
  4. 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!
  5. 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.
  6. 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>; }; };
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. @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.
  13. 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.
  14. @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
  15. 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. Спасибо, что поделились!
  16. 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.
  17. 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
  18. https://patchwork.kernel.org/project/linux-amlogic/patch/20201030180057.23886-1-christianshewitt@gmail.com/ ^ tested by the maintainers .. enjoy :)
  19. Ahh, that would bump our figures too. LibreELEC's greatest advances over the years have been fueled by people who were unemployed, soon-to-be unemployed, or on long-term sick-leave. I had high hopes for the pandemic driving a creative spurt but we seem to have scraped by without anyone falling victim (as nerds, we're too good at social distancing).
  20. Amlogic has no real-world interest in Armbian or any other mainline tracking Linux distro so they are not going to fork over any $$$ for support. Their business is heavily focussed on Android and some other niche use-cases. Like most/all SoC manufacturers, their responsibilities are to their customers (integrators who buy their silicon chips) and their shareholders, not consumer end-users in the Linux community who want to reflash a $30 device with a $0 distro image that doesn't use any of their software (which is a good thing, the BSP sucks). "Board" devices from any vendor are generally simple to support since the vendor ships u-boot and kernel sources with varying levels of contact and engagement with the community. "Box" devices are a completely different game, with a massively larger amount of guesswork required to get working and a huge issue with device cloning and hidden spec changes. For example; the current X96-Air (S905X3) model which is popular ships in three different configurations and has been witnesssed with 4x different SDIO WiFi/BT chips; which necessitate a different device-tree file to have the right drivers (which mostly don't exist in mainline) probed. These devices are great when they work, but mostly they don't, and they're a massive and frustrating time sink to support, and the percentage of self-entitled users who get whiny about them seems to be an order of magnitude greater than those using boards. So any sane distro maintainer will (and should) focus on supporting boards. Once in a while there will be box exceptions, but they will be infrequent. Any attempt to cause deliberate harm to user installations via software is unethical and I would expect the Armbian forum moderators to take appropriate action to deny promotion or access to such images via this forum if that actually happened. I know that I would take swift action to delete posts/threads and perhaps temp-ban users if this happend in the LibreELEC forums. However I suspect some of the alarm is caused by GoogleTranslate more than Oleg .. it does seem to translate Russian > English with very firm (borderline aggressive) words. Once in a while I've made him post in his native language, which I can read/undertand to a moderate level, and the tone is different. As a side note, I'm stunned to hear that Armbian running costs are 2,000-5,000 EUR per-day .. LibreELEC runs around $2,500 per year
  21. Linux 5.7 has support for MT7668 Bluetooth, but not WiFi, and the Linux 4.9 (Android) driver that can be found in a few places does not compile on recent kernels. I suck at forward porting but might have a look into it as there are a few S905X2/X3 devices with this chip. The firmware was upstreamed to the kernel back in 2018, but no drivers yet.
  22. I'm not sure if it's relevant, but 26386440 looks rather large for an LE kernel .. we normally compress things: LibreELEC (chewitt): 9.80.0 (AMLGX.arm) SDCARD:~ # ls -l /flash/ total 106856 -rwxr-xr-x 1 root root 10739122 Jan 1 1980 KERNEL -rwxr-xr-x 1 root root 98639872 Jan 1 1980 SYSTEM drwxr-xr-x 2 root root 8192 Jan 24 12:35 extlinux -rwxr-xr-x 1 root root 26926 Mar 16 18:26 meson-gxbb-wetek-play2.dtb Current LE master nightly is here (different boot scripts to Oleg's images): https://test.libreelec.tv/LibreELEC-AMLGX.arm-9.80-nightly-20200324-aeb6e84-nanopi-k2.img.gz
  23. since there's a willing volunteer .. I'm interested to know whether this works from SD card as K2 is maybe the only board I don't have https://test.libreelec.tv/LibreELEC-AMLGX.arm-9.80-nightly-20200316-9542570-nanopi-k2.img.gz If the file is deleted, there'll be another nightly in the same folder.
  24. hmm... if I flash the C2 image to my WeTek Play2 and boot .. I get this: GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3;RCY:0;EMMC:0;READ:0;CHK:0; TE: 116845 ***** Warning!! ***************************************************** * This board have not been autorized or product keys are not valid. * * Please contact with Hardkernel or your distributor * ********************************************************************* So the board checks for BL1 in the first sector too, but the HK binary used for C2 clearly checks against something board specific so it cannot be used elsewhere. In other words, there's a software solution to this stupidity but (as is often the case) it's all closed-source proprietary crap. Time to go short some pins and clear the emmc again
  25. This is also worth a read: https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/attachments/slides/3342/export/events/attachments/one_image_to_rule_them_all/slides/3342/simage.pdf I've concluded that on GXBB (and likely Meson6/8) devices the BL1 embedded in the SoC looks for BL2 in the first sector of emmc, and this prevents normal emmc partitioning as the MBR/GPT structures also use the first sector and will overwrite BL2 and break the boot process. The GXBB BL1 looks for the BL2 signature at a different offset on SD cards, which allows space for the patition tables, and it looks like GXL and newer SoC's check the "SD card" offset on both emmc and SD, which is why mainline u-boot recipes for newer devices can use u-boot.bin.sd.bin for both emmc and sd media. Poking around in the bsp u-boot code shows drivers/mmc/aml_emmc_partition.c which appears to show creation of a reserved area at the front of disk for u-boot.bin with BL2 in the first sector, and then MBR/GPT structures at an offset value. The partition layout is then described in device-tree, allowing u-boot to see /dev/mmcblkX and mount a filesystem to boot. The non-standard Amlogic partition arrangement means normal partitioning tools won't work, as they attempt to read the tables in the first sector and don't find anything there. I have an Odroid C2 where the emmc module is removable. I'm guessing this is presented in hardware like an SD card (or Bl1 is different, but I think that's unlikely) allowing C2 to boot from the SD offset. I don't own a NanoPi K2, so not sure how that presents. TL/DR; the best compromise for LE users is to image an SD card containing mainline u-boot.bin.sd.bin and then partition/format internal emmc as persistent /storage. It's then just a trivial sed of the extlinux.conf to switch disk=LABEL=STORAGE (sd) to disk=LABEL=EMMC_STORAGE (emmc) and reboot to benefit from faster /storage I/O for Kodi access to thumbnails.
×
×
  • Create New...