add ODROID-C4/N2/N2+/C2 support for RPI-RF-MOD/HM-MOD-RPI-PCB integration #1323
Conversation
|
FYI: I updated this PR to also support the ODROID N2/N2+ hardware line after having tested it myself with appropriate hardware. |
|
Another minor update: Added ODROID-C2 support and tested it accordingly. |
|
@agners Any chance to get this PR reviewed and merged anytime soon? |
|
@jens-maus haven't looked closer, but there are some linter errors, are they new with this pull request? |
|
@agners nope, they are coming from your shellcheck CI action (ludeeus/action-shellcheck@1.0.0) you are using in your CI setup. I had the same in my project as I am also using the shellcheck CI action there and unfortunately the shellcheck action always uses the latest released shellcheck version (currently 0.7.2) rather than fixing it to a certain version and thus new error/problems might suddenly come up. In my case I had to add certain |
|
@jens-maus yeah I am aware that we run shellcheck and all, was more wondering why those suddenly crop up. It seems in that case we haven't touched the file for a long time, so it did not show up in pull requests. I'll fix those up. |
| @@ -0,0 +1,3 @@ | |||
| # disable "deprecated CP15 Barrier instruction" warnings | |||
| # https://www.kernel.org/doc/Documentation/arm64/legacy_instructions.txt | |||
| abi.cp15_barrier = 2 | |||
There was a problem hiding this comment.
Why is that needed? C4 is a 64-bit target, no 32-bit software or even ancient 32-bit software using CP15 barrier instructions should be running on it.
There was a problem hiding this comment.
Well, not within the Buildroot/Linux OS itself, but e.g. the RaspberryMatic HA add-on comes with 32bit binaries (because the upstream vendor (eQ3) didn't yet supply 64bit binaries) and thus with a complete 32bit multilib environment (see https://github.com/jens-maus/RaspberryMatic/tree/master/buildroot-external/package/multilib32). And thus, 32bit apps actually (can) run within a docker environment and thus uses the CP15 barrier instructions. Thus, I would prefer to keep that minor sysctl tuning because it stops the kernel flooding for which I didn't find any other way to silence these messages.
|
|
||
| +&i2c3 { | ||
| + status = "okay"; | ||
| + pinctrl-0 = <&i2c3_sda_a_pins>, <&i2c3_sck_a_pins>; |
There was a problem hiding this comment.
I prefer this patch over the hacked up patches below since it makes use of existing pinctrl's. I am planning to upstream this patch.
Can you leave this in, and rebase the other ones on this one (e.g. remove i2c3 and just add i2c2?
There was a problem hiding this comment.
As stated in the PR description, I have largely borrowed the kernel patches for the hardkernel/odroid platform from the armbian project (see https://github.com/armbian/build/tree/master/patch/kernel/archive/meson64-5.10). And as the proposed patches are dependent on eachother I decided to drop your patch in favour of the official armbian-based patchsets. However, if you insist I could of course see if I can keep your patch and rework the others. But then they are not compatible to the armbian patches anyone and thus might be harder to be updated in future in case armbian integrates more changes.
There was a problem hiding this comment.
official armbian-based patchsets
Often those are downstream patches, and I already inherited breaking changes in the past.
"Official" in my eyes is whatever is upstream. And if there are upstream patches available which do the same thing, I prefer those since I can just delete them once we move to newer kernel.
In this case there seem to be patches already merged at least for I2C3/RTC:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
So this should be a simple cherry-pick.
There was a problem hiding this comment.
Since I am currently working on ODROID-N2 anyways I can prepare a patchset today which should be an equivalent change and then you can rebase your changes on-top. Is that ok for you?
There was a problem hiding this comment.
That's perfect with me, thanks.
|
Please note that I have rebased this PR to latest dev and removed the not required kernel patches accordingly. However, there are still some additional kernel patches in this PR which are targeted for the ODROID-C2 and ODROID-C4 to setup the i2c and uart nodes in the device tree correctly. Looking forward to your continued review and integration. |
|
@jens-maus thanks! Yeah I am aware about C2/C4. Those platforms are not as important as N2, so I think we can also address that at a later point. I'll check the PR today and merge it to do another dev build. There will be an rc later this week. |
This PR complements the previously merged PR on the
RPI-RF-MOD/HM-MOD-RPI-PCBhardware integration support (cf #1266) by adding support for the Hardkernel Odroid-C4/N2/N2+ hardware as well.Thus, this PR adds necessary changes to
uart_A) and thei2c2andi2c3bus enabled via borrowed patch files from the armbian project (https://github.com/armbian/build/tree/master/patch/kernel/archive/meson64-5.10).generic_raw_uartrpi-rf-modpackage/etc/sysctl.d/30-cp15barrier.confsysctl config file which setsabi.cp15_barrier = 2to ensure that the kernel log is not flooded bydeprecated CP15 Barrier instructionwarnings in case legacy 32bit applications might be used within third-party add-ons (e.g. the RaspberryMatic add-on) which still use CP15 instructions (cf. https://www.kernel.org/doc/Documentation/arm64/legacy_instructions.txt)Looking forward to get this PR merge ASAP because I think it would be great to have that already onboard when HAos 6.0 is about to be released.