The question in the title. It looks like for RK3288, Allwinner A20/H3 are really the only options, outside of iMX6 price levels and Raspi-2 ?
S805 seems like a bit rough still ?
I'm basically trying to find a lowest performance device out there that can still somewhat run on something relatively close to mainline, with moderate hacking as needed.
Get a Raspberry Pi 3B+ .. or even the 2GB 4B model. For the sake of $20 difference in price you can have something reliable and not needing to be on the bleeding edge of development. Do you prefer to watch movies or forever chase down fixes?
I've actually got a stack of various boards, various variants of S9xx and S805, RK3288s included, and a bunch of Raspberrys, 2, 3 and 4 as well. I'm not looking to watch movies in this instance ( although i do watch a lot of movies ), I'm looking for slowest possible 32-bit chipset with hardware video playback support, to basically use as a stress test target for some custom software.
I've been able to get Tinkerboard / RK3288 running with 5.7-rc kernels with latest Panfrost and Mesa 20, but video playback seems relatively broken still. I've got Odroid-c1 for S805 testing, have gotten it somewhat running with trunk kernels, but it's still quite unstable, and it doesn't look like it's seeing much activity anymore for testing or development.
Original RPi (1) boards are probably the slowest but still stable things that we're still technically supporting. NB: Meson 8* Lives! might dispute your S805/C1 theory but there are no public images at this time.
Thanks for that thread. I'll definitely try and see if i can get my odroid-c1 lights on with the patch series from here GitHub - xdarklight/linux at meson-mx-integration-5.8-20200428
The Ethernet perf fix looks especially encouraging: LKML: Martin Blumenstingl: [PATCH RFC v2 00/11] dwmac-meson8b Ethernet RX delay configuration
There are some things that need to be removed from device-tree and forced via u-boot before you'll get HDMI output on C1. It's very active but also very slow progress.
Any pointers to where to look ?
For Armbian on C1, i had to mess with uboot env a bit too, convert zImage->uImage, given it's ancient uboot fork, and a few other bits and pieces, as listed in this thread here Armbian (EOS) - Make it boot - ODROID
I have a weekend of hacking time ahead, if i get the lights on, i'd probably push a branch somewhere
FWIW, did get the lights on ODROID-C2. Otherwise stock master build with DEVICE=AMLGX UBOOT_SYSTEM=odroid-c2, but removed all pre-existing kernel patches and reset to meson-mx-integration-5.8-20200503 from GitHub - xdarklight/linux: Various Linux kernel changes - Amlogic Meson (32-bit and 64-bit) SoCs, lantiq SoCs, ath9k, etc.. - see branch list.
Had to limit SSD speed to get it to boot, otherwise was getting errors like these
Running bBuild info:Code
- LibreELEC:/ # uname -a
- Linux LibreELEC 5.7.0-rc4 #1 SMP Tue May 5 15:35:51 UTC 2020 aarch64 GNU/Linux
- LibreELEC:/ # head -n 8 /storage/.kodi/temp/kodi.log 2020-03-06 12:38:59.531 T:691 INFO <general>: -----------------------------------------------------------------------
- 2020-03-06 12:38:59.531 T:691 INFO <general>: Starting Kodi (19.0-ALPHA1 Git:392dcf7331e06afda77d957d12664d3e1dc6c714). Platform: Linux ARM 32-bit
- 2020-03-06 12:38:59.531 T:691 INFO <general>: Using Release Kodi x32 build
- 2020-03-06 12:38:59.531 T:691 INFO <general>: Kodi compiled 2020-05-05 by GCC 9.3.0 for Linux ARM 32-bit version 5.6.0 (329216)
- 2020-03-06 12:38:59.531 T:691 INFO <general>: Running on Amlogic Meson GXBB (S905) Hardkernel ODROID-C2 with LibreELEC (community): devel-20200506031328-8ddef2d 9.80, kernel: Linux ARM 64-bit version 5.7.0-rc4
- 2020-03-06 12:38:59.531 T:691 INFO <general>: FFmpeg version/source: 4.2.2-Kodi
- 2020-03-06 12:38:59.531 T:691 INFO <general>: 4 CPU cores available
- 2020-03-06 12:38:59.531 T:691 INFO <general>: ARM Features: Neon enabled
- LibreELEC:/ # lsmod
- Module Size Used by
- fuse 143360 3
- uas 32768 0
- 8021q 40960 0
- rfkill 40960 1
- meson_vdec 81920 1
- videobuf2_dma_contig 24576 41 meson_vdec
- videobuf2_memops 20480 1 videobuf2_dma_contig
- v4l2_mem2mem 49152 1 meson_vdec
- governor_simpleondemand 16384 0
- videobuf2_v4l2 36864 2 meson_vdec,v4l2_mem2mem
- videobuf2_common 57344 3 meson_vdec,videobuf2_v4l2,v4l2_mem2mem
- lima 61440 1
- ir_nec_decoder 20480 0
- rc_odroid 16384 0
- gpu_sched 36864 1 lima
- meson_ir 20480 0
- ao_cec 20480 1
Plays a little bit of video, something funny going on with HDMI timing as well, image is a bit jumpy.
Will try the same with C1
Odroid C1 is an arm (32-bit) device. Odroid C2 is an arm64 device. You need to do more than simply change the kernel source, i.e. define a device with an arm(32) defconfig and CPU params.
Yes i know of course. I just figured it's a good starting point, i more or less learned how to use the LE build system effectively without rebuilding the world every time, make quick custom branches for kernels, and get reproducible fast full builds with Docker running on Amazon / Fargate.
I'm referencing old LE branches, H3 device definition and Armbian build trees to try and pull C1 definition together. It's coming along, but slowly, as i have only a bit of time to tinker with it.
Oh, and i should probably configure things for tftpboot rather than switching sdcards out, hardkernel has pretty good support for it.
^ this is the minimum. Odroid C1 needs a bootable image so I'm still experimenting with the least-worst way to combine prehistoric pre-built u-boot and our more mainline u-boot oriented build-system so those bits are not in any of my branches yet.
Oh, thanks a lot, this helps me forward a ton. Weekend coming up, I'll mess with it and report back what i can get to work.
Just out of interest, is having amlogic upstream u-boot support a lost cause ? allwinner seems to be doing this real nicely. I've got A20, H3 and H5 boards here all booting with really recent u-boot code.
There is basically no upstream support for Meson 8 in u-boot right now, and while some bits of GXBB support might also be reusaable I'm not aware of any plans for someone to look at it. Plus you still have to contend with design mistake on all pre-GXL Amlogic SoCs where boot firmware needs to run in the first sector of eMMC which means you can't use normal partition tables.