chewitt

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).

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

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.

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

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.

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

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.

This was an interesting find .. flagged by one of our contributors once I started moaning about Amlogic's needs https://github.com/Kwiboo/u-boot/commit/6d0a17632922077a2e64b13ae1a6bdf0024b718f

I'll do some experiments - thanks for the notes and suggestions. Worst case I'll force users to boot from SD (which works fine) and we can format the emmc for use as /storage in LE which is where Kodi keeps all the persistent data that needs I/O performance. The base image on a WeTek Play2 box is booting from SD (including WLAN connection) in ~10 seconds (see http://ix.io/25Ts) so we're not exactly un-performant.

Once all the clocking and pin-control and other stuff is done the Mali T820 bit is trivial .. Amlogic S912 (also T820) is now on parity with T860/T760 and other devices using panfrost.

I found this thread while working on mainline u-boot support for the WeTek Hub/Play2 boxes that LE has historically supported "internal" (emmc) installs on. These will not be compatible with mainline Linux as it doesn't support Amlogic's partition scheme. So I started investigating a bump to mainline u-boot. Using u-boot.bin.sd.bin worked fine booting from sdcard, but dd'ing it to /dev/mmcblk1 resulted in "GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3; .. " so BL1 cannot find u-boot. I've done a little poking around, so here's /dev/mmcblk1 with the default LE image that uses u-boot.bin.sd.bin: LibreELEC:~ # hexdump -C -n1024 /dev/mmcblk1 00000000 e8 cb ef 87 91 8e 91 8a 4d 7a f0 5d ba d4 90 92 |........Mz.]....| 00000010 2a 94 c4 e3 b4 fb b5 e7 7b 95 62 2f e9 d9 61 d1 |*.......{.b/..a.| 00000020 a4 51 58 35 df ea bf 2c 64 af 8a 1e 83 1a b0 ae |.QX5...,d.......| 00000030 ae 74 91 62 70 46 49 eb db ac 1a c4 85 7c 95 29 |.t.bpFI......|.)| 00000040 cd ed 5f ac d7 1e d9 3b ce 63 5a 51 7d 0a ff 2b |.._....;.cZQ}..+| 00000050 7f 90 8d ef d6 d7 da b1 83 f5 75 08 71 0a 31 3e |..........u.q.1>| 00000060 f8 90 ea cf af c3 0b 7d 26 65 ce a3 6f ce ce ee |.......}&e..o...| 00000070 5e 5c dd 35 33 b8 e6 b6 ad 5c be 1e 66 ef 5c 5e |^\.53....\..f.\^| 00000080 80 46 2e 2f 0a 39 ac 30 9e 7a d4 0d 48 a2 fc a7 |.F./.9.0.z..H...| 00000090 fe d9 dc 31 91 c2 e7 3e 1e a5 5c 85 95 b8 e3 15 |...1...>..\.....| 000000a0 ff 11 44 09 4a f0 39 e8 6a 0d f6 b3 b0 f2 5a ae |..D.J.9.j.....Z.| 000000b0 cb 36 e0 5d f8 c7 9b 17 6d f8 9c 02 b0 7f 17 af |.6.]....m.......| 000000c0 91 5b b8 db 4b f2 c4 b5 ff ba 68 af ac c2 5e 77 |.[..K.....h...^w| 000000d0 f8 3e d4 f1 05 70 08 72 68 a4 74 18 23 8b c8 b4 |.>...p.rh.t.#...| 000000e0 e6 80 90 31 72 54 e7 72 0e 4f 21 ba 12 7f 31 0a |...1rT.r.O!...1.| 000000f0 bd 06 fb c3 76 03 35 de a7 aa f6 cb 35 be 7f 1c |....v.5.....5...| 00000100 3f 0f 4d b1 63 34 23 71 84 45 2b 96 c4 5d a0 82 |?.M.c4#q.E+..]..| 00000110 63 9c 45 d9 9f 7a b7 47 24 ad 12 5a 6c 91 76 ab |c.E..z.G$..Zl.v.| 00000120 a1 c3 5c 04 f8 80 76 7c c5 a1 12 89 fe b2 0b 61 |..\...v|.......a| 00000130 4e 50 3a ee cb f1 35 ef 9f 47 49 0b d8 bf b6 79 |NP:...5..GI....y| 00000140 83 12 7e 7b 92 f4 f7 57 95 09 e1 94 bb ec f5 0a |..~{...W........| 00000150 3d 30 f8 08 21 2d f7 c0 74 41 cb 4c 00 81 c6 83 |=0..!-..tA.L....| 00000160 94 44 fe 26 38 f5 7e cd fe 5f 61 ba 4b 57 c4 88 |.D.&8.~.._a.KW..| 00000170 87 bc 90 a8 e9 88 69 5d c9 34 a9 c9 b6 6f 4d 4a |......i].4...oMJ| 00000180 b3 4b 70 eb 41 ee b9 3f 4d 1a f9 99 71 bd 21 f8 |.Kp.A..?M...q.!.| 00000190 79 b2 a1 62 3a 0a bf 03 3e 69 cc f4 d8 19 3e 8c |y..b:...>i....>.| 000001a0 65 af 77 a6 9d 30 e5 eb 4b df 84 bc 9c a5 b5 16 |e.w..0..K.......| 000001b0 57 56 78 91 60 38 94 9e a1 61 93 79 00 00 80 00 |WVx.`8...a.y....| 000001c0 01 40 0c 03 e0 ff 00 20 00 00 00 00 10 00 00 03 |.@..... ........| 000001d0 e0 ff 83 81 cb b6 00 20 10 00 00 e0 d8 00 00 00 |....... ........| 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 10 40 e4 32 d7 56 04 32 b8 20 37 d2 32 80 e0 7b |.@.2.V.2. 7.2..{| 00000210 40 41 4d 4c f0 bf 00 00 40 00 01 00 00 00 00 00 |@AML....@.......| 00000220 00 00 00 00 40 00 00 00 00 02 00 00 60 00 00 00 |....@.......`...| 00000230 00 00 00 00 40 02 00 00 b0 0d 00 00 90 bf 00 00 |....@...........| 00000240 00 00 00 00 f0 0f 00 00 00 b0 00 00 00 00 00 00 |................| 00000250 a1 f2 25 3d 4c b2 10 fe 58 42 14 97 cd 58 c7 73 |..%=L...XB...X.s| 00000260 94 4c 19 85 00 c5 40 af 21 66 83 8b be c1 d1 05 |.L....@.!f......| 00000270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 and here's what the mainline u-boot.bin looks like .. the @AML offset is clearly different: LibreELEC:~ # hexdump -C -n1024 u-boot.bin 00000000 3f 9b 44 08 b9 fb df f2 87 55 b4 99 53 f7 25 05 |?.D......U..S.%.| 00000010 40 41 4d 4c f0 bf 00 00 40 00 01 00 00 00 00 00 |@AML....@.......| 00000020 00 00 00 00 40 00 00 00 00 02 00 00 60 00 00 00 |....@.......`...| 00000030 00 00 00 00 40 02 00 00 b0 0d 00 00 90 bf 00 00 |....@...........| 00000040 00 00 00 00 f0 0f 00 00 00 b0 00 00 00 00 00 00 |................| 00000050 a1 f2 25 3d 4c b2 10 fe 58 42 14 97 cd 58 c7 73 |..%=L...XB...X.s| 00000060 94 4c 19 85 00 c5 40 af 21 66 83 8b be c1 d1 05 |.L....@.!f......| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 and here's the bootloader.img file wetek shipped in a firmware update (2015 vendor bsp u-boot): LibreELEC:~ # hexdump -C -n1024 bootloader.img 00000000 c4 56 10 90 0e 2b ad ce 29 d9 e9 30 61 96 ab 57 |.V...+..)..0a..W| 00000010 40 41 4d 4c f0 bf 00 00 40 00 01 00 00 00 00 00 |@AML....@.......| 00000020 00 00 00 00 40 00 00 00 00 02 00 00 60 00 00 00 |....@.......`...| 00000030 00 00 00 00 40 02 00 00 b0 0d 00 00 90 bf 00 00 |....@...........| 00000040 00 00 00 00 f0 0f 00 00 00 b0 00 00 00 00 00 00 |................| 00000050 9c 44 c5 b2 46 69 b1 f7 ed fd f3 3b 7b b3 e6 91 |.D..Fi.....;{...| 00000060 be 67 8b db 78 b4 36 33 bf 11 2f 7b 01 2d 3e 39 |.g..x.63../{.->9| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 If I zero the emmc and run "dd if=u-boot.bin of=/dev/mmcblk1" and shutdown/boot the box, I see nice things: GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3;RCY:0;EMMC:0;READ:0;CHK:0; no sdio debug board detected TE: 109572 BL2 Built : 09:01:42, Oct 11 2016. gxb g88b04d6 - haixiang.bao@droid05 set vcck to 1100 mv set vddee to 1000 mv Board ID = 4 CPU clk: 1536MHz DDR chl: Rank0+1 diff @ 912MHz DDR0: 1024MB(auto)-2T-13 DDR1: 1024MB(auto)-2T-13 DataBus test pass! AddrBus test pass! -s Load fip header from eMMC, src: 0x0000c000, des: 0x01400000, size: 0x00004000 New fip structure! Load bl30 from eMMC, src: 0x00010000, des: 0x01000000, size: 0x0000d460 Sending bl30......................................................OK. Run bl30... Load bl31 from eMMC, src: 0x00020000, des: 0x1010[0000, size: 0x00018190 Image: gxb_v1.1.3135-18177fc 2016-06-24 11:00:09 yun.cai@droid06] OPS=0x13 cb 1 53 1 a5 56 7d bf a3 1d f5 91 [0.197378 Inits done] secure task start! high task start! low task start! Load bl32 from eMMC, src: 0x0003c000, des: 0x05300000, size: 0x00035760 Load bl33 from eMMC, src: 0x00074000, des: 0x01000000, size: 0x00093850 NOTICE: BL3-1: v1.0(debug):bc3419d NOTICE: BL3-1: Built : 14:16:22, Aug 15 2016 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Initializing BL3-2 INFO: BL3-2: ATOS-V1.5-g3e467d9 #1 Mon Aug 22 17:11:43 CST 2016 arm INFO: BL3-2: chip version = RevC (1F:C - 0:0) INFO: BL3-2: crypto engine BLKMV INFO: BL3-2: secure time REE INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x1000000 INFO: BL3-1: Next image spsr = 0x3c9 U-Boot 2020.01-rc5 (Dec 29 2019 - 14:21:09 +0000) wetek-play2 Model: WeTek Play 2 SoC: Amlogic Meson GXBB (S905) Revision 1f:c (13:1) DRAM: 2 GiB MMC: mmc@70000: 0, mmc@72000: 1, mmc@74000: 2 In: serial Out: serial Err: serial [BL31]: tee size: 0 [BL31]: tee size: 0 Net: Warning: ethernet@c9410000 (eth0) using random MAC address - ae:4d:80:01:69:e9 eth0: ethernet@c9410000 Hit any key to stop autoboot: 0 Card did not respond to voltage select! switch to partitions #0, OK mmc2(part 0) is current device ** No partition table - mmc 2 ** starting USB... No working controllers found USB is stopped. Please issue 'usb start' first. starting USB... No working controllers found ethernet@c9410000 Waiting for PHY auto negotiation to complete.... and if I do "dd if=u-boot.bin.sd.bin of=/dev/mmcblk1 bs=512 skip=1" and shutdown/boot the box, I see the same UART output. now I need to figure out how to combine the extracted u-boot with a partitioned filesystem. So far each time I partition and format I break u-boot .. but I'll get there eventually

I did some diff'ing of u-boot code against the existing public sources back in August and while the total changeset is rather huge, most of the complexity added is associated with the recovery system that Realtek implemented. I think it should be possible (and IMHO beneficial) to isolate the smaller set of changes that provide actual board support and port them to a more modern u-boot (ideally mainline) and then you don't smack your head against the recovery stuff all the time. https://github.com/chewitt/u-boot/commits/bpiw2 has my low-quality u-boot n00b hacking to try and clean-up the boot process to reduce noise and increase comprehension of what's going on. The include/configs/rtd1295_common.h file is where the current u-boot env is set. The single biggest thing that would be useful is git history.. but that's unlikely, although I will submit the nag via some realtek people I tracked down via LinkedIn.

I sort-of object to the word "published" when GPLv2 code is offered from a private repo with docs marked "Realtek Confidential" .. but I guess it's a form of progress?

The repo contains an incomplete/unsuccessful attempt to port the driver to mainline kernels around 4.18/4.19 time. Even by the unbelievably low standards of 3.14 vendor bsp kernel drivers the code is fugly awful crap. In researching the origin of the sources I had one of the Rockchip driver team we collaborate with (based in China; native Mandarin speaker) phone around some of the chip distributors to ask Q's and it appears "South Silicon Village" (the SSV in ssv6051) went bust in 2016 so there's zero hope of getting newer sources (but the distibutors still have stock and are still offering a good deal to those who seek the cheapest chips). There's another Github repo (also doesn't compile work) that hints the driver is really a clone/rip-off of a Realtek design (although I forget which one) but some LE people experimented with some Realtek sources changing ID's and such but never got anything to work. TL/DR; If you have hardware with that chipset .. the cheapest $2 used Realtek USB wireless thing you can find on eBay is miles better NB: I've now added **NOT WORKING** to the Github repo description.

Couple of issues solved. First the SD card drivers weren't being built due to CONFIG_SYS_CONFIG_NAME="rtd1295_qa_sd_bananapi" not being set in the u-boot config. Second one of the Sinovoip/Foxcon staff confirmed that u-boot has a 20MB size limit on the kernel. I was using an uncompressed uImage that also contains the LE initramfs that was ~22MB in size. Switching to a gzip KERNEL file dropped size to 10MB and working from the u-boot console I can fatload files etc. to reach this point: ## Booting kernel from Legacy Image at 03000000 ... Image Name: Image Type: AArch64 Linux Kernel Image (gzip compressed) Data Size: 11108954 Bytes = 10.6 MiB Load Address: 03b00000 Entry Point: 03b00000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02100000 Booting using the fdt blob at 0x2100000 Uncompressing Kernel Image ... OK reserving fdt memory region: addr=0 size=100000 reserving fdt memory region: addr=1f000 size=1000 reserving fdt memory region: addr=1ffe000 size=4000 reserving fdt memory region: addr=2200000 size=400000 reserving fdt memory region: addr=2600000 size=c00000 reserving fdt memory region: addr=3200000 size=b800000 reserving fdt memory region: addr=10000000 size=14000 reserving fdt memory region: addr=14200000 size=9200000 Using Device Tree in place at 0000000002100000, end 000000000210e694 Bring UP slave CPUs Starting Kernel ... but nothing on the console after that point, and I have set 'bootargs' using both the config in the original sinovoip env, and the settings that LE normally uses. The sequence of commands i'm running is effectively this: setenv bootargs earlycon=uart8250,mmio32,0x98007800 fbcon=map:0 boot=/dev/sda1 disk=/dev/sda2 ssh textmode console=ttyS0,115200n8 console=tty0 setenv fdt_loadaddr 0x02100000 setenv kernel_loadaddr 0x03000000 setenv audio_loadaddr 0x0f900000 setenv kernel KERNEL setenv dtb_name rtd-1296-bananapi-w2-2GB-HDMI.dtb setenv audio bluecore.audio fatload sd 0:1 ${fdt_loadaddr} ${dtb_name} fatload sd 0:1 ${kernel_loadaddr} ${kernel} fatload sd 0:1 ${audio_loadaddr} ${audio} bootm ${kernel_loadaddr} - ${fdt_loadaddr} I've also experimented with /dev/mmcblk0p1 and /dev/mmcblk0p2 .. and 1p1/1p2 and boot=UUID and boot=LABEL combinations - it's not clear what would be correct. Any suggestions?

LE (on an SD card) uses two partitions. The first is fat (512MB) containing boot files; notably KERNEL (the kernel) and SYSTEM (rest of the OS in a SQUASHFS file). We normally use extlinux to boot board devices that need their own u-boot, but i'm not sure that will be an option here. The second partition is ext4 and provides persistent storage. The overall first partition structure of the Ubuntu image that I downloaded from Sinovoip looks similar to Amlogic (only less organised) where we are using bootm with a uEnv.ini file, and some boot scripts.

Using @Staars u-boot and kernel repo's I managed to create a basic image using the LibreELEC build system (using Armbian's would require an old dog to learn new tricks). I know little about u-boot, but I appear to have created an SD card image that fails and ends up in the 2015 u-boot that was compiled from sources: BPI-W2> version U-Boot 2015.07 (Aug 01 2019 - 04:17:12 +0000) aarch64-libreelec-linux-gnueabi-gcc-8.3.0 (GCC) 8.3.0 GNU ld (GNU Binutils) 2.32 BPI-W2> As you can see/guess, this is on W2, the switch is set to boot from SD card. Full boot log: Are any of you hanging around in IRC channels on freenode? .. I could use some help tweaking the boot files/contents to get the kernel working.