I was trying to enable i2c on my RockPro64,  and when looking at the documentation in the overlay directory, it states this:

rockchip (Rockchip)

### Provided overlays:

- i2c7, i2c8, pcie-gen2, spi-spidev, uart4, w1-gpio

### Overlay details:

### i2c7

Activates TWI/I2C bus 7

I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4

### i2c8

Activates TWI/I2C bus 8

I2C8 pins (SCL, SDA): GPIO1-C5, GPIO1-C4

 

 

Note that the  "GPIO1-C5, GPIO1-C4" from i2c8 is accidentally included on the i2c7 pins line.

 

I would submit a PR for this change,  but ... I'm not sure where this document actually lives, and it's not easy to figure out.

 

I see that @Igor  is listed as the maintainer of the package, but that's not helping me find the source to submit changes.

 

Also, for clarity, it would be nice to include that    i2c8  is the pi-connector,  and  i2c7  is the Digital Video Port

 

Happy to submit changes if somebody can point me to the right place.

 

Thanks

$ git clone https://github.com/armbian/build

$ cd build

$ find . -type f -exec grep -F 'I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4' '{}' +

./patch/kernel/archive/rockchip64-5.12/general-rockchip-overlays.patch:+I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4
./patch/kernel/archive/rockchip64-5.10/general-rockchip-overlays.patch:+I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4
./patch/kernel/archive/rockchip64-4.4/general-rockchip-overlays.patch:+I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4
./patch/kernel/archive/rockchip64-5.14/general-rockchip-overlays.patch:+I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4
./patch/kernel/archive/rk3399-4.4/general-rockchip-overlays.patch:+I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4
./patch/kernel/archive/rockchip64-5.15/general-rockchip-overlays.patch:+I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4
./patch/kernel/archive/rockchip64-5.13/general-rockchip-overlays.patch:+I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4
./patch/kernel/media-edge/general-rockchip-overlays.patch:+I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4
./patch/kernel/media-current/general-rockchip-overlays.patch:+I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4

# to understand above invocations
$ man find

 

 

yes, the patches are there in multiple directories from historical use.

 

But the question that's really being asked is " are those patchfiles the correct place to PR against,  or is there someplace upstream where they're managed"

 

because... patching a diff file seems  really incorrect.

 

 

 

 

On 2/12/2022 at 12:27 AM, ak_hepcat said:

yes, the patches are there in multiple directories from historical use.

 

Yes, only those that are linked from EDGE and CURRENT are relevant to be changed.

 

On 2/12/2022 at 12:27 AM, ak_hepcat said:

or is there someplace upstream where they're managed"

overlays are pretty distro specific features. Anyway most arm oriented distros are directly using our kernel or patches, so more upstream is only kernel.org, but AFAIK there they don't deal with overlays.

Okay, so...  again...

 

Should i perform a PR against the patchfile itself?

 

Or is there a master repo somewhere else that's it's generated from that would be more appropriate?

 

specifically for:  armbian/patch/kernel/media-edge/general-rockchip-overlays.patch

None of this patch process seems to be documented anywhere, so, I'm struggling with how to get changes made in the correct manner.

 

Now I am certainly no authority, but reading between the lines of what Igor said, I think that yes maybe submitting a PR against our build repo may indeed be the correct place?

 

On 2/11/2022 at 11:27 PM, ak_hepcat said:

because... patching a diff file seems  really incorrect.

 

Maybe it makes sense from the perspective that Armbian is actually a build system, rather than a distro in the normal sense, even though we do also publish pre-built images.

 

And so, those patches get applied to some sort of kernel source or another, during the build process.

 

On 2/14/2022 at 8:20 PM, ak_hepcat said:

None of this patch process seems to be documented anywhere, so, I'm struggling with how to get changes made in the correct manner.

 

In my time here, I have gathered that the ARM Linux ecosystem is kind of wild and wooly, with random patches and fixes coming from here and there...  Armbian in fact is an effort to try and unify all these things floating around on the Internet into some sort of cohesive whole.  Which I guess is why we maintain our own patch sets.

 

Your efforts toward contribution are appreciated.

1 hour ago, TRS-80 said:

[...]

In my time here, I have gathered that the ARM Linux ecosystem is kind of wild and wooly, with random patches and fixes coming from here and there...  Armbian in fact is an effort to try and unify all these things floating around on the Internet into some sort of cohesive whole.  Which I guess is why we maintain our own patch sets.

 

Your efforts toward contribution are appreciated.

 

welp,  I guess that's where i'll head then.   Ugly as sin, but... it is what it is.

 

Heading off to PR...  ( https://github.com/armbian/build/pull/3495  )

 

thanks!