Contribution Question - MKS IPS50 HDMI, ST7796 LCD, MKSPI/SKIPR Boards

[MaxM]

Hi here,

 

as a hobby project I forked Armbian repo to add support of someone "new" hardware, mostly around 3D printing and mostly because no support from the vendor side.

 

At this moment I have following almost independent components:

1. a kernel module for ST7796 (LCD controller connected via SPI and working as frame buffer module/device)
2. a patch for HDMI configuration to support MKS IPS50 screen (800x480, 5:3 aspect ration with some weird EDID)
3. configuration with related patches for MKSPI, SKIPR and a few derivatives boards + some DTS overlay for one related/specific use case. It's a "Renegade ROC-RK3328-CC" based board(s) which was adapted for some specific use cases (kinda "cost effective" alternative of Raspberry PI with pretty deep adaptions for for 3D printers)

 

Is there are any interest to contribute these changes to official Armbian code base? If yes, which of these parts?

 

Additional remarks:
1. At the moment, these changes have been tested on real equipment (to the best of my knowledge and capabilities ) and have proven stable enough for everyday usage.
2. I am not a Makerbase/MKS developer and have no any connection with this company. It's my "weekends project" for my personal purposes.
3. Fork repo: https://github.com/redrathnure/armbian-mkspi

 

 

Best regards and thank you for your efforts,

Maxim

[robertoj]

I am interested in the ST7796 kernel module

 

 

Can anybody check whether Sitronix ST7796 is included in the current or latest kernel? fb or drm?

[MaxM]

Hm... looks like there is a ST7796*S*  driver for some sunxi64 boards. However it has `S` suffix and init sequence is different. Should I try to open PR with rockchip64-6.6/general-st7796-driver.patch ?

[Igor]

On 11/30/2024 at 11:44 PM, MaxM said:

as a hobby project I forked Armbian repo to add support of someone "new" hardware

Nice to see that you managed to put our build framework into good use!  

 

Build configuration can be .conf, if you plan to keep it maintained here, else it can be .csc (community configuration). ! tl;dr; version of support policy can be found here  https://docs.armbian.com/User-Guide_Board-Support-Rules/ 

 

On 11/30/2024 at 11:44 PM, MaxM said:

Is there are any interest to contribute these changes to official Armbian code base? If yes, which of these parts?

Code wise, not an issue, all of it, until it met common coding standards (quick check = it does) and that it doesn't break anything else (which I also believe it won't). Remaining problem is the instructions part ... We currently don't have any, not right, not wrong place in the documentation to keep that kind of things well organised. A comment with URL in board config file can do for now.

 

On 11/30/2024 at 11:44 PM, MaxM said:

Additional remarks:

Most of contributions to Armbian are done in similar way. 

[MaxM]

OK, let's do it step by step.

 

The first one would be PR#7543 for ST7796 LCD module.

 

About board(s) related changes, I have a few questions:

 

1. We are talking about `Community maintained` support if I cannot participate in a "Release Process" and attend periodic "development meeting", right?

2. DTS for this board(s) was done by patching already existed `/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts`, which originally introduced for Renegade SBC. It looks bit weird for me... and sometimes gives extra issue with adjusting/reverting previously applied patches (for the `rk3328-roc-cc.dts` file). Should I try to introduce a separated DTS file for my case? Like it was done for these boards.

Edited December 6, 2024 by MaxM

[Igor]

9 hours ago, MaxM said:

We are talking about `Community maintained` support if I cannot participate in a "Release Process" and attend periodic "development meeting", right?

 

Minimum of this is that testing is done at major kernel bumps. We are switching to K6.12 with CURRENT branch, which is main objective and where things will break down for sure. This has to be tested and fixed (if possible) in / by the next release month (2/2025). Them we will stay on that kernel for some time and little will break at 5 and 11 / 2025. We would like to have "supported" boards at least tested. If images are broken, telling that we know that and we know someone is working on it, also works. Perhaps someone else will show up and help around this ... Its more like a grey zone as this is for most of the people a hobby.

 

9 hours ago, MaxM said:

Should I try to introduce a separated DTS file for my case?

Yes, better.

[MaxM]

11 hours ago, Igor said:

 

Minimum of this is that testing is done at major kernel bumps. We are switching to K6.12 with CURRENT branch, which is main objective and where things will break down for sure. This has to be tested and fixed (if possible) in / by the next release month (2/2025). Them we will stay on that kernel for some time and little will break at 5 and 11 / 2025. We would like to have "supported" boards at least tested. If images are broken, telling that we know that and we know someone is working on it, also works. Perhaps someone else will show up and help around this ... Its more like a grey zone as this is for most of the people a hobby.

It should not be a problem. I already align my patches with armbian/main so this board is ready for 6.6 and 6.12. And testing images for major kernel bumps should not be a problem neither.

 

11 hours ago, Igor said:

Yes, better

OK, I will try to do this.

[MaxM]

The second part is ready (core support of new boards for edge and current streams). Please have a look and notify me if any additional patches or documentation is needed.