[RFC 001] Changes for boards and features implementing

[balbes150]

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 December 30, 2018 by Tido
to keep the thread clean I have splitted it. See link at p.s.

[JMCC]

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.

[JMCC]

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.

[NicoD]

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.

[Igor]

2 hours ago, JMCC said:

But if it is necessary to do it as in the second option

IMO ideally, not necessary.

[JMCC]

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.

[JMCC]

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.

[selfbg]

@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

 

[Igor]

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

[Igor]

48 minutes ago, selfbg said:

owever I'm not sure how this will work with the existing condition

https://github.com/armbian/build/commit/813f5e037cdbe62106fdfddf43238b30f73fe0f2

I assume it's nothing wrong if this is enabled on default, otherwise we need to add one IF sentence there.

[selfbg]

2 hours ago, Igor said:

https://github.com/armbian/build/commit/813f5e037cdbe62106fdfddf43238b30f73fe0f2

I assume it's nothing wrong if this is enabled on default, otherwise we need to add one IF sentence there.

 

Yes, but the service will always fail, since there isn't support for H5 protocol in kernel 3.4.

[gprovost]

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.

[Igor]

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.

[gprovost]

@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 ?

[Igor]

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.

[gprovost]

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.

[gprovost]

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.

 

 

[Igor]

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.

[balbes150]

@Igor  When you start getting the full version of the firmware, through the interface "armbian-config", the old version 5.60 is downloaded and installed (there are not important firmware files "meson" for HW on Aml S9xxx). Can you update this package on the server (at least to version 5.72, it has these files), so that can use the firmware for the decoder based on the main kernel ?

[Igor]

1 hour ago, balbes150 said:

@Igor  When you start getting the full version of the firmware, through the interface "armbian-config", the old version 5.60 is downloaded and installed (there are not important firmware files "meson" for HW on Aml S9xxx). Can you update this package on the server (at least to version 5.72, it has these files), so that can use the firmware for the decoder based on the main kernel ?

OK, will put out an update in next 1-2h. 

I also tried to merge things today, but its getting complicated since your build script is not a fork and history is not compatible. I am not that git expert so I do struggle a bit ...

 

I am also thinking to cleanup your sources first, to deal with a complexity. First stage to remove what is deprecated and do some cleanup.  Can we set some detailed actions? Shell we go step by step, family by family? Hot to effectively test this? I don't have much hardware to run tests.

[balbes150]

1 hour ago, Igor said:

OK, will put out an update in next 1-2h. 

I also tried to merge things today, but its getting complicated since your build script is not a fork and history is not compatible. I am not that git expert so I do struggle a bit ...

 

I am also thinking to cleanup your sources first, to deal with a complexity. First stage to remove what is deprecated and do some cleanup.  Can we set some detailed actions? Shell we go step by step, family by family? Hot to effectively test this? I don't have much hardware to run tests.

You can make a temporary branch to merge and test in your GIT. You will add whatever you see fit. I will download this version of the test brunch, build test images with it, check and write the result (or add the necessary direct patches for this test brunch, which you can apply without using git on a local copy).

[balbes150]

If add in the name of the collected packages (deb) the info when it is assembled (year_month_date), it will automatically track the appearance of new packages in online repositories by means of standard Synaptic\apt. For example " armbian-config_5.74_190208_".

[gprovost]

@Igor How things are looking ? You think the merge to master might still happen this month ?

[Igor]

38 minutes ago, gprovost said:

@Igor How things are looking ? You think the merge to master might still happen this month ?

I am not yet confident enough to do this. I also have unplanned personal issues which will be taking me a lot of time for the next two months.

Let's discuss steps:

 

- rename master to stable. Keep it default? For how long? How to maintain two even one is barely possible?

- rename tvboxes to master

- add a note about this change

- accept PR only on a new branch?

- make a forum announcement

- beta.armbian.com is getting updates from this new branch
- dealing with this problem on the way https://github.com/armbian/build/pull/1129

 

 

[gprovost]

I would suggest the following but I'm sure I'm missing your overall vision

 

46 minutes ago, Igor said:

- rename master to stable. Keep it default? For how long? How to maintain two even one is barely possible? 

Let it as master, and master branch remain the default branch. Later this current master will be renamed as old

 

46 minutes ago, Igor said:

- rename tvboxes to master

Rename it as dev

When ready to make the pivot following this RFC, copy the dev branch and name it master (which will be then the default branch)

 

46 minutes ago, Igor said:

- accept PR only on a new branch? 

Only accept PR on dev branch

Merge dev to master when ok to do.

 

To be considered :

- maybe there is not need of a distinction between next and dev, therefore next become also dev

- moving all the current 'next kernel' as 'default kernel'. Cleaning up old distrib also.

[balbes150]

As an option. Rename the "master" branch to "master-old". Branch "tvboxes" - > " master "and additionally make the branching" tvboxes " - > "dev". The "dev" branch can be used to receive all PRS. There's all PR tested within a certain period of time and if the rest of the collectors do not have problems with the proposed PR in the Assembly of the rest of the images or if there are no comments for change/improvement/delete  to PR, he goes to "master". 

 

Along the way, I would suggest adding this option of MPV settings to all DE images. With this option, video playback works well on all Amlogic Rockchip Allwinner models without using HW. I checked, when switching video to full screen option, with these settings on all, even the weakest models, the video works in full screen with acceptable quality (for all screen resolutions up to 1080).

 

https://github.com/150balbes/build/blob/tvboxes/packages/bsp/mpv/mpv_mainline.conf

[gprovost]

Can we have an update status on this RFC. What's the plan / roadmap ?

[Igor]

Development is stalled, it also seems to need some revision and rethinking. Perhaps its going to wrong direction, perhaps its already too big (for one person) to handle? Perhaps moving chunk by chunk of what has for sure been done better to the master? Build system should become less complex, but it seems its getting more. I would propose to move kernel patches 1st out from the main script first, then perhaps do the same with BSP recipes packaging as well? And a good manual has to be done on the way, otherwise it will remain very costly to maintain .. which again leads nowhere.

[lanefu]

Development is stalled, it also seems to need some revision and rethinking. Perhaps its going to wrong direction, perhaps its already too big (for one person) to handle? Perhaps moving chunk by chunk of what has for sure been done better to the master? Build system should become less complex, but it seems its getting more. I would propose to move kernel patches 1st out from the main script first, then perhaps do the same with BSP recipes packaging as well? And a good manual has to be done on the way, otherwise it will remain very costly to maintain .. which again leads nowhere.

@igor I really would like to capture the all the tasks for refactoring the build scripts and track them as a project in github.

To your point, if the tv boxes branch is no longer solving problems, then we may not want to invest effort into that branch


Sent from my iPad using Tapatalk

[Igor]

2 hours ago, lanefu said:

is no longer solving problems

Certain problems are solving ... but I am deeply concerned about problems which will be made if not done properly.

 

2 hours ago, lanefu said:

I really would like to capture the all the tasks for refactoring the build scripts and track them as a project in github.

Yes, lets try. It seems we need to start using some project tracking. At least for more complex situations.