Allwinner H313 chip adaptation problem

linsz · January 2, 2025 at 9:28 AM New

Hi, I have a question, if I want to adapt Libreelec to the H313 chip, then what do I need to modify in the project to get H313 support, or whether there is an official H313 support that is just not released

**chewitt** · January 2, 2025 at 10:18 AM New

There's no special/secret repo that we're sandbagging support for that chip in .. support doesn't exist and you need to adapt Linux kernel drivers for H6 and H616 to the H313 hardware and/or author new drivers for anything missing. There is no guide for how things are done, only prior-art from the Allwinner BSP codebase as an example: mostly an example of how to write low-quality code that needs to be rewritten for upstream frameworks, standards, and acceptance.

We'll be happy to test anything you come up with.

linsz · January 2, 2025 at 11:22 AM New

First of all, I have a version of ubuntu that works on H313 hardware. Secondly, my understanding of libreelec lies in that it cross-compiled and packaged a bunch of packages into image package files through scripts. The most important problem is that maybe due to my ability, I still can't understand how libreelec runs, so I don't know how to modify it to effectively adapt it. So I was hoping you could give me some guidance. For example, replace certain files in certain directories or modify certain configuration files to fit.

**chewitt** · January 3, 2025 at 7:27 AM New

Your Ubuntu image will be using the Allwinner (downstream) vendor codebase. It would be a good first-step to compile the latest Kodi for Ubuntu and understand if (and how) it runs there. These days LE is heavily oriented around a modern kernel and overall codebase that supports GBM/V4L2 graphics and this is often the opposite of what vendor codebases provide.

LE is not derived from any other OS and is loosely based on Linux from Scratch principles: https://www.linuxfromscratch.org

The wiki has basic buildsystem instructions on how to self-compile: https://wiki.libreelec.tv/development/build-basics

Our buildsystem is full of prior-art and acts as it's own instruction manual. One of the trueism's of the project is that people with the right skillsets/background to succeed with device bring-up/porting occasionally show up with esoteric questions on distro packaging or some compile issue, but they never show up asking how to approach the task as for them it's obvious and they're already neck-deep in the required changes. At the risk of being "Mr Negative" on the idea: I can tell from what and how you're asking that you're in the wrong camp (as I would also be .. it requires non-trivial effort).

**jernej** · January 3, 2025 at 7:11 PM New

If you want to play, here is my attempt: https://github.com/jernejsk/LibreELEC.tv/commits/h616/ but note that display driver is not there yet (problematic scaling of YUV formats). There is also no audio support. Using newer kernel would allow analog audio and if you use extra patches, also hdmi audio.

linsz · January 13, 2025 at 1:13 AM New

First of all, thank you very much for the resources you provided me. Secondly, I have a question whether the title you provided as H616 is applicable to H313. I know they have a chip with similar performance, and how do I compile it to get the image I need, since I don't see the device option under the Device branch of the Allwinner directory.

**jernej** · January 13, 2025 at 5:31 AM New

They use same silicon, they are just named differently, because (i think) they differ in performance. Yes, you can use same code.

linsz · January 13, 2025 at 7:33 AM New

If I am using it for a box, do I need to select aarch64 or arm in the ARCH compilation option?

I don't know if you know about Emuelec system, in fact, my ultimate goal is to run Emuelec on H313, because I found that there are a lot of netizens want to H313 Emuelec, so I think this is a very meaningful thing. However, as the basis of Emuelec, Libreelec did not adapt to H313, so I wanted to adapt libreelec first and then gradually realize the adaptation of Emuelec, but Emuelec involves libreelec, coreelec, emuelec three parts. It takes a lot of time to fully understand and implement the adaptation, so I hope to find an expert in this field to lead me to implement the adaptation of H313. At present, my biggest advantage is that I have all the existing resources needed for H313.

linsz · January 13, 2025 at 12:22 PM New

Hello, when I use your source code to compile the image package and burn the SD card to insert the box after the following situation, and repeated printing

**chewitt** · January 13, 2025 at 1:18 PM New

The error message is quite clear, no?

**jernej** · January 13, 2025 at 7:06 PM New

This means that you didn't select correct U-Boot config. U-Boot has to be configured for each board separately, due to different settings, like DRAM (as you already experienced). Board configuration is done here: https://github.com/LibreELEC/Libr…ts/uboot_helper

linsz · January 14, 2025 at 2:25 AM New

I changed config, but it got stuck in some configuration and stopped going, nothing I typed worked, how do I fix it to keep it running?

**jernej** · January 14, 2025 at 5:27 AM New

you have to provide DRAM settings, which you can get in Android DT file from vendor image.

linsz · January 14, 2025 at 5:55 AM New

Cannot BSP U-Boot be used? Does it mean I need to replace the U-boot or just modify the DRAM.

**jernej** · January 14, 2025 at 5:15 PM New

No, only mainline U-Boot is supported (currently 2025.1.) If your board is already supported, great, all you need to do is to set correct config name in uboot_helper script. If not, you have to create patch for U-Boot, which introduces correct defconfig for your board and then put it in uboot_helper script.