3 3
Igor

[RFC WIP] Changes for boards and features implementing

Recommended Posts

On 12/28/2018 at 8:08 PM, NicoD said:

Do you know if hardware encoding could be available for the RK3399's? 

In Libreelec (KODI-18) on Khadas EDGE (RK3399) play all video works. Including HW for 4K and sound.

 

 

p.s. pls test  https://forum.armbian.com/topic/8898-ramblings-and-progress-with-the-rk3399/?do=findComment&comment=68690 

 

Edited by Tido
to keep the thread clean I have splitted it. See link at p.s.

Share this post


Link to post
Share on other sites
On 12/28/2018 at 8:08 PM, NicoD said:

Is this for 4K video for the RK3399? I've tried the newest FriendlyElec image but didn't have luck with this. I'll try the core image tonight. On the RockPi4B in Kodi in Recalbox 4K video's play well, but sound doesn't yet work there. 
Do you know if hardware encoding could be available for the RK3399's?

 

If you need something tested, please let me know.

I'm now making a video about video editing on SBC's. The RK3399's are the best for this, but 1080p video preview isn't perfect now. So if this could be fixed, then this would be awesome news.
I should record my video this weekend, but I can wait with it if I could improve the experience.

Thanks for the great work, greetings.

Yes, I already have 4K video playing working in RK3399, with MPV and GStreamer. Kodi seems like a tough cookie, I'm still working on it (I made it work in a 32-bit version, but I am missing something for the 64-bit compile). Even HEVC 10-bit plays fine.

 

About encoding, didn't test it yet, but it should work too.

Share this post


Link to post
Share on other sites
On 12/10/2018 at 10:37 PM, Igor said:

If some 3rd party packages needs to be placed to the repository, put them here

So what is best, uploading the packages to that repo or integrating their build in the script, here? Of course, the first option is easier, I build them locally in my machine and upload them. But if it is necessary to do it as in the second option, I would need some help (probably from @zador.blood.stained) on how to implement it.

Share this post


Link to post
Share on other sites
6 minutes ago, JMCC said:

Yes, I already have 4K video playing working in RK3399, with MPV and GStreamer. Kodi seems like a tough cookie, I'm still working on it (I made it work in a 32-bit version, but I am missing something for the 64-bit compile). Even HEVC 10-bit plays fine.

 

About encoding, didn't test it yet, but it should work too.

That`s great news, do you have a walkthrough for this? Or an image with it working? No problem it`s for 32-bit.
I need it to work in Kdenlive. When it works with MPV then I should be able to make it work there. 
Many thanks.

Share this post


Link to post
Share on other sites
20 hours ago, Igor said:


IMO ideally, not necessary.

In that case, I will start by uploading the compiled packages, and then slowly learn how to integrate the build into the script. Otherwise, we would not be able to meet the February deadline for this.

Share this post


Link to post
Share on other sites
23 hours ago, NicoD said:

That`s great news, do you have a walkthrough for this? Or an image with it working? No problem it`s for 32-bit.
I need it to work in Kdenlive. When it works with MPV then I should be able to make it work there. 
Many thanks.

I'll upload the script when it is finished. However, I don't understand what you mean by making Kdenlive work from a working MPV (I guess it has something to do with MLT and MPV having FFMpeg in common). You can start a thread for this in "General chit chat", and tag me, so we can discuss this.

Share this post


Link to post
Share on other sites

@Igor I've build an image for A20-SOM204 (next), but bluetooth service doesn't load. I guess the code from armbian.build should be moved to armbian.postinst. However I'm not sure how this will work with the existing condition:

 

if [[ $BRANCH != default ]]; then
...
fi

 

Share this post


Link to post
Share on other sites
9 minutes ago, selfbg said:

I've build an image for A20-SOM204 (next), but bluetooth service doesn't load. I guess the code from armbian.build should be moved to armbian.postinst. However I'm not sure how this will work with the existing condition:


I see. It will work this way:
https://github.com/armbian/build/blob/tvboxes/config/packages/99-board/dedicated/pinebook-a64/armbian.postinst.bash

Share this post


Link to post
Share on other sites
On 12/18/2018 at 12:36 AM, Igor said:

Another issue is u-boot. We will drop u-boot package installation for all boards. Only compiling, packing and writing. But we need to have "write_uboot_platform" definitions for nand-sata-install and/or manual install/update via armbian-config ...

 

Instead why not keep installing the u-boot package for all boards but we remove the postinst script from u-boot package and replace it by a message saying to user to use armbian-config to write new version of u-boot to target. I would make things simpler.

Share this post


Link to post
Share on other sites
2 minutes ago, gprovost said:

Instead why not keep installing the u-boot package for all boards


Because we have to learn on mistakes, not repeating them.  You can easily deal with 1-2 issues which will come out of this situation, while for us this number can easily jump to several hundreds - considering lower quality and high count with Allwinner board. We can't deal with such situations.

Share this post


Link to post
Share on other sites

@Igor The approach of just extracting u-boot dpkg intead of installing it will then only concern fresh install then. What about people with an already running system where u-boot dpkg is installed ? Then when they do an upgrade their u-boot will still get updated !

 

If the idea is to avoid auto update of u-boot for all board, then removing the post-inst script from u-boot package is the best approach. In any case what the point to keep it moving further ?

Share this post


Link to post
Share on other sites
1 minute ago, gprovost said:

then removing the post-inst script from u-boot package is the best approach. In any case what the point to keep it moving further ?


Aha, didn't understand you correctly. Yes, perhaps that is a better option - to leave package as is, but move script to armbian-config.

Share this post


Link to post
Share on other sites
12 minutes ago, Igor said:

Aha, didn't understand you correctly. Yes, perhaps that is a better option - to leave package as is, but move script to armbian-config.

 

Yes correct, we remove postinst script in u-boot package.

 

Then in armbian-config / nand-sata-install we add a new option with title "Update u-boot on $BOOT_DEVICE". This option will just do write_uboot_platform $DIR $BOOT_DEVICE.

 

Update: If you ok then I will do a PR.

Share this post


Link to post
Share on other sites
On 12/11/2018 at 5:37 AM, Igor said:

Upgrade path is not determined yet - I only focused on packaging and installing.

 

@Igor I think need to be careful here to no encourage people to already take in consideration upgrade path.

 

Before (current master branch) board tweaks were only applied during build. So any changes in those tweaks would not get propagated to users with apt upgrade. Only choices for them were either to do fresh install or to manually change the tweak on target.

 

Now with this RFC, tweaks are move to deb package. Those board deb packages I supposed will get published in the APT repo, and their version will increment through time ??

 

Some of those tweaks implies to modify some files in the rootfs with via pre/postinst scripts. Therefore it's important to take in consideration the fact that during board package upgrade maybe those files which require tweaks have already been modified by the pre/postinst scripts of previous board package version.

 

I'm pretty sure some of the pre/postinst script out there will mess up files in the rootfs by trying to apply tweak on an already tweaked file.

 

So to avoid any future nightmare, you should encourage people to already take in consideration the upgrade path. The other benefit to do so, is that this new RFC would then also maybe work for upgrading pre-RFC system.

 

Maybe it was clear to everyone but I think it's worth to be clarified.

 

 

Update:

Here an example : https://github.com/armbian/build/blob/tvboxes/config/packages/99-board/dedicated/cubietruck/armbian.postinst.bash

At every upgrade this postinst script would add an additional MACADDR line with a new MAC address in file /etc/default/brcm40183. I guess this is not what you want, so it's why it's important to emphasis upgrade path handling.

 

 

Share this post


Link to post
Share on other sites
1 hour ago, gprovost said:

I think need to be careful here to no encourage people to already take in consideration upgrade path.


I expect that it will be in around 2 months. Certainly not now. I did several sweeps and I always find something to fix - if you find something odd and you are sure what has to be done, simply send a PR.

 

Since packages has different naming (except u-boot, kernel and dtb) upgrade is in fact optional.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
3 3