chewitt

  • Content Count

    18
  • Joined

  • Last visited

About chewitt

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. https://patchwork.kernel.org/project/linux-amlogic/patch/20201030180057.23886-1-christianshewitt@gmail.com/ ^ 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): https://test.libreelec.tv/LibreELEC-AMLGX.arm-9.
  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 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.
  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: 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 pati
  9. 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
  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 http://ix.io/25Ts) 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 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.bi
  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. https://github.com/chewitt/u-boot/commits/bpiw2 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