search

orangepi-xunlong / orangepi-build

Orange Pi build for H2+, H3, H5, H6, H616, RK3328, RK3399 and RK3588(s)
http://www.orangepi.cn/
GNU General Public License v2.0
725 stars 298 forks source link

Q. Any interest on submitting OrangePI 5/5B (rk3388s) into mainstream Linux kernel? #77

Open waltercool opened 1 year ago

waltercool commented 1 year ago

Hi,

I know OrangePI supports Debian/Ubuntu-only distributions under Kernel 5.10, but is there any intention to decentralize this to upstream kernel like OrangePI (rk3399) or OrangePi R1+ (RK3328) ?

Specially when Rock 5A already submitted and approved a RK3588s board for 6.3, and NanoPi R6S also sent patches for their RK3588s board https://patchwork.kernel.org/project/linux-rockchip/list/?series=&submitter=&state=*&q=rk3588s

Asking because, while official support is nice, it also gives some downs like:

Thanks.

cpainchaud commented 1 year ago

+1 !

DaveWK commented 1 year ago

+1 -- Would love to see the 5B added. I suspect getting these reviewed and merged is more time consuming. Looking over this codebase, it is very difficult to see what the actual differences between mainline kernel and the orangepi fork are. I suspect a lot of the customization were because of the lack of an official driver at one point or another, but a lot of the drivers are now in mainline (and some even have improvements from when they were copied from one place or another).

I would really prefer having the orangepi changes separated from the main kernel releases to make it easier to test and upgrade the kernel, since a lot of the problem for anyone attempting to contribute to orangepi dev and testing work is that it is very hard to see what customizations were made for a 2 year old fork and which ones are still relevant. Keeping the customizations in a separate folder wold be a big help. I don't really like git patches for this because when there's multiple changes to the same files it becomes a mess of serial git patches, and the indentation gets ruined by git patch syntax.

waltercool commented 1 year ago

There are more cons than pros on that scope:

Pros:

Cons:

I tried to merge some changes to mainstream kernel 6.2, but the amount of customization are not minor. It looks like on linux-orangepi 5.10-rk3588 are just 18 commits, but you also must consider all changes from RockChip kernel 5.10, which are a lot, at least over 500 commits of new files, workarounds and fixes for own chips.

The way this works usually is:

DaveWK commented 1 year ago

yeah, I totally agree -- I think the issue has been compounded by the amount of time that the fork in this repo has been stale has compounded the problem. I think we're in agreement; my first remark was just an observation that the manufacturers are probably rushing out new boards faster than they would be potentially merged into the kernel.

My thought was pinning a submodule for this repo to a mainline kernel commit so there's a known starting point., for example:

mainline-kernel/<submodule here>
modifications/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts

then the flow for a build would be:

cp modifications/* mainline-kernel/.
cd to the mainline subfolder and build the kernel

Then the git commit pinned in the submodule could be easily adjusted on releases to allow for regression testing/release management.

I also have tried to get this version rebased to v6.2, but like you have also seen there's not really a linear set of commits which would bring it into mainline because of the rockchip kernel modifications and such. Without a known starting point, it makes it very domain-knowledge intensive to know what changes have been made here and but later were upstreamed in an entirely different commit or format, and not merged back or removed from these branches. for instance there's not an easy way to tell if orangepi made any changes to hotfix the rk808 driver that aren't in mainline or if all these changes are no longer needed now that rk808 is in mainline.

waltercool commented 1 year ago

Thing is, they will unlikely accept those changes. Some changes made are very "Rockchip specific", while Linux Kernel tries to reuse as much as possible.

Also changes from 5.10 to 6.2 will fail. Current DTS fails to compile even by copying modifications. Already tried it.

Several Rockchip boards are already at mainline, and some developers are already pushing changes for RK3388 and RK3388s from other boards... but just supporting the board doesn't mean too much, still requires identification and fixes USB, sensors, power button, HDMI, GPIO... etc. also code if required for GPU (Mali) and some I2C controller

DaveWK commented 1 year ago

yeah, I have also tried and failed to get the u-boot repo for orangepi up to a more recent version to try and pick up the UEFI changes from mainline but there's so many variable name/syntax/sort ordering changes that it's very difficult to spot what the real differences are.

tanmaster commented 1 year ago

I too would love this.

nairn62 commented 1 year ago

FYI. v6.2 and v6.3 is possible on the Orange Pi 5. I tried the image from this link, and I can confirm it works booting up v6.2 https://forum.armbian.com/topic/27588-kernel-62-hdmi-usb-lan-etc-for-opi5

waltercool commented 1 year ago

Nice, I still would wait for that developer to share the source code on that. Will ask at that post.

Just trusting the kernel image and dtb from someone at internet at binary format might not be a good idea.

orangepi-xunlong commented 1 year ago

https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-rk3588

https://github.com/manjaro-arm/opi5-images/releases

msalawat commented 1 year ago

Lets's test images from https://github.com/manjaro-arm/opi5-images/releases

DaveWK commented 1 year ago

Update: https://lore.kernel.org/lkml/cover.1692372351.git.efectn@6tel.net/ -- this is great news!

waltercool commented 1 year ago

Great! Thank you very much for the information Dave, let's see if gets approved on the next Linux releases.

I do expect a basic support initially, even with the large DTS configuration sent for RK3588s, that's fine. We had the same on RK3328. I'm sure orangepi-xunlong have some custom modifications to achieve full support (Rockchip kernel base) at expense of staying out of mainbase.

Maintaining a kernel is a very difficult work.

Should we resolve this ticket?

katyo commented 1 year ago

Good news! What about GPU and HDMI support? Also I hope Orange Pi 5 Plus will be added soon.

adminy commented 1 year ago

Any updates on this? Can Orange Pi 5 Plus be booted with latest kernel??

coolva commented 1 year ago

Also having hopes for the 5 Plus!

tcx4c70 commented 1 year ago

It seems that the latest linux kernel has been basically basically supported orange pi 5 / orange pi 5 plus (https://lore.kernel.org/lkml/96986a4b-b9d5-4fdb-bfa6-1d75ec31ade6@app.fastmail.com/)!

Original patchset:

  1. orange pi 5: https://lore.kernel.org/lkml/cover.1696878787.git.efectn@6tel.net/
  2. orange pi 5 plus: https://lore.kernel.org/lkml/20231008130515.1155664-1-megi@xff.cz/, but it seems that it doesn't support usb3.0 for plus now.

But I don't have opi5 / opi 5 plus on my hand, so I doesn't test it manually.

LAP87 commented 11 months ago

I got an OPI5 (bought early bird last december and only tested a few times), been waiting for this! What can i do to help test this?

tcx4c70 commented 10 months ago

Linux 6.7 is just released and it can boot on my Orange Pi 5 Plus image

However, it can only boot, there are still lots of device which can't work:

  1. HDMI doesn't work. xrandr will report that Can't open display. There are lots of changes to drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c in armbian kernel (~4000 lines) vs mainline kernel (~700 lines).
  2. Lots of sensors can't be detected. sensors will show No sensors found.
  3. LED is always red. I'm not sure whether the driver is missed in kernel or some configs or control scripts are missing in user mode.

Hope that someday I can boot from mainline kernel and all devices can work properly.