• Content Count

  • Joined

  • Last visited

Everything posted by chewitt

  1. ^ tested by the maintainers .. enjoy :)
  2. 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).
  3. 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 ge
  4. 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.
  5. 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):
  6. 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 If the file is deleted, there'll be another nightly in the same folder.
  7. 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 elsewhe
  8. This is also worth a read: 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 pati
  9. This was an interesting find .. flagged by one of our contributors once I started moaning about Amlogic's needs
  10. 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 so we're not exactly un-performant.
  11. 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.
  12. 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 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
  13. 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. has my low-quality u-boot n00b hacking to try and clean-u
  14. 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?
  15. 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
  16. 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 Kern
  17. 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.
  18. 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