Closed aciceri closed 2 years ago
@aciceri hi, I'd like to see the PR if nothing else so that I can take a look at it. I feel like it might make sense to have a community repo where this kernel could be maintained, keep an eye on megous's patch set, etc. Then projects like mobile-nixos could just re-use it for the pinetab/pinephone? idk.
Do you mean a repository only for the pinebook pro's kernel patched by megaous? Why don't simply add support inside nixos-hardware
? To be honest I would move this entire repository inside nixos-hardware
, I was even reading that they were talking about using nix-community
's Hydra server(s).
However what I did is really simple, boot.kernelPackages
is the standard linuxPackages_latest
from unstable
, instead as boot.kernelPatches
I passed this:
let
json = ./patches.json;
patches = builtins.fromJSON (builtins.readFile json);
manjaro-kernel = pkgs.fetchgit {
url = "https://gitlab.manjaro.org/manjaro-arm/packages/core/linux.git";
rev = "ad338c8941d322575119d504a98336e7c0931be9";
sha256 = "0kfzrcfxr0spfck5q1mc71d290rqirjac4zybw5a28x9yyj65yhn";
};
create-patch = p: {
name = p;
patch = "${manjaro-kernel}/${p}";
};
in
map create-patch patches
where patches.json
is this file:
[
"3172-arm64-dts-rk3399-pinebook-pro-Fix-USB-PD-charging.patch",
"3174-arm64-dts-rk3399-pinebook-pro-Improve-Type-C-support.patch",
"3176-arm64-dts-rk3399-pinebook-pro-Remove-redundant-pinct.patch",
"3376-drm-rockchip-cdn-dp-Disable-CDN-DP-on-disconnect.patch",
"3392-usb-typec-fusb302-Set-the-current-before-enabling-pu.patch",
"3396-usb-typec-fusb302-Update-VBUS-state-even-if-VBUS-int.patch",
"3398-usb-typec-fusb302-Add-OF-extcon-support.patch",
"3399-usb-typec-fusb302-Fix-register-definitions.patch",
"3400-usb-typec-fusb302-Clear-interrupts-before-we-start-t.patch",
"3401-usb-typec-typec-extcon-Add-typec-extcon-bridge-drive.patch",
"3402-phy-rockchip-typec-Make-sure-the-plug-orientation-is.patch",
"3457-phy-rockchip-inno-usb2-More-robust-charger-detection.patch",
"3458-usb-typec-extcon-Don-t-touch-charger-proprties.patch",
"3459-arm64-dts-rk3399-pinebook-pro-Don-t-allow-usb2-phy-d.patch"
]
I don't know why I used a json, maybe because it would be simpler to edit with an automatic tool? I think I would remove it the PR.
Before making the PR I want to retry building the kernel directly using megaous' git as src
without passing any patches. I think it's cleaner, I could implement it similar to how nixos-mobile
is currently doing with the pinephone.
@samueldr @colemickens Tell me what do you think, frankly I would entirely move this repository's content inside nixos-hardware
(moreover that repository is a flake, I never understood why #15 has never been merged)
+3 from me on everything :heart:
Not sure how @samueldr feels but I'd be happy to review/test a PR for nixos-hardware, or try my hand at it if you don't want to.
Well, I made the offer this about the same time someone actually took me up on an offer for my unused Pinebook Pro. Since they seem very excited and very much more likely to *actually use the device**, I'm going to send it to them and I have to rescind my offer to test. But I'd still be happy to test-build/review just to see it through.
I mean... https://github.com/samueldr/wip-pinebook-pro/issues/25...
Though the main issue right now is I don't have to maintain/manage all this. So yeah, it can be migrated to nixos-hardware.
Oops, I didn't see that issue, anyway I'm happy to see that there was the intention to move to nixos-hardware
.
These days I'm really busy but I think I'll definitely try to send a PR on that repository in a week or two.
@colemickens your review would be really useful for me, thank you! I don't have much experience with these things and i am trying to learn. However I understand you, I don't actually use the device too, it's a nice toy but it is also an end in itself for my needs.
When I'll make the PR in the other repository (trying to move this entire repository) I'll ping you both then.
I managed to build the latest kernel on
unstable
(5.16.3) with these patches from Manjaro and now I can correctly output the video using an USB Type-C -> HDMI/VGA adapter.If there was interest I could integrate the derivation here (that explicitly specifies the kernel's
src
so that it can't stop building if the upstreamlinuxPackages_latest
get updated (I remember having this problem in the past)). Moreover, since building time is not negligible, at least one using this overlay wouldn't have to rebuild the kernel every time he updates the channel/flake inputs.Maybe I could do that if one import the derivation without specifying anything a pinned kernel's
src
is used, otherwise he can specify which version he wants to use.Side issue: it would be cool to have a github action that build the kernel and then push it on a Cachix cache. I already did something like this so I could implement it except that I was never able to cross compile using Github actions, so I don't think that way is viable. Another solution could be to ask to use
nix-community
's Hydra servers but I've zero experience with that software.@samueldr Meanwhile can I proceed with a PR with only the derivation?