Still supported 32-bit chipset options ?

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

  • 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:



    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.

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