ayufan

Members
  • Content Count

    5
  • Joined

  • Last visited


Reputation Activity

  1. Like
    ayufan got a reaction from TonyMac32 in Switching Rockchip64-DEV to 5.0.y ...   
    I plan from my side to bump to u-boot 2019.01, both for rock64 and rockpro64. I used them in the past, but I wanted to have power of using DDR (Rockchip one, as I'm not sure if it still supports DDR4, there was a problem with that for long time) with a custom SPL on top to bring SPI and other support
     
     
    I almost rebased all my kernel patches both for 4.4 and 5.x to be very minimal set on top.
     
  2. Like
    ayufan got a reaction from lomady in One (bsp) Kernel f RK3399/RK3328 and RK3288   
    I posted this comment: 
    that discribes a little my kernel
     
  3. Like
    ayufan got a reaction from TonyMac32 in NanoPC T4   
    I actively rebase my kernel on top of rockchip-linux to keep a list of patches somehow compact. My current workflow is not very good for community contribution, still: this is rebase of commit history, but I'm happy to change that.
    One thing that is probably unique about my kernel that I release a new kernel version after every: https://gitlab.com/ayufan-repos/rock64/linux-kernel/ and https://github.com/ayufan-rock64/linux-kernel and this is released as debian packages that you can put on any distro and apt-get install: http://deb.ayufan.eu/ayufan-rock64/linux-kernel. In my latest builds, I effectively moved from building kernel each time to installing kernel/u-boot package for simplicity and split of responsibility (single resp repository).
     
    Anyway. I don't want to be a bottleneck, so I would say that the best would be to start a new common repo branch and rebase all our work on this branch, give a few people review/merging capabilities and based the work on the good will of people. I know that being alone and reviewing/accepting is a job that can get boring, as you also need to ensure the quality, splitting the responsibility here is desirable. Now, I do all the stuff there myself, but also I only have to check rock64/rockpro64 which is to be fair not a lot of hurdle for me, but with more dependence on this work we simply need more people.
     
    I somehow like the rebase workflow that we always keep a small number of patches, but I'm fine with merge workflow too
     
  4. Like
    ayufan got a reaction from tkaiser in NanoPC T4   
    I actively rebase my kernel on top of rockchip-linux to keep a list of patches somehow compact. My current workflow is not very good for community contribution, still: this is rebase of commit history, but I'm happy to change that.
    One thing that is probably unique about my kernel that I release a new kernel version after every: https://gitlab.com/ayufan-repos/rock64/linux-kernel/ and https://github.com/ayufan-rock64/linux-kernel and this is released as debian packages that you can put on any distro and apt-get install: http://deb.ayufan.eu/ayufan-rock64/linux-kernel. In my latest builds, I effectively moved from building kernel each time to installing kernel/u-boot package for simplicity and split of responsibility (single resp repository).
     
    Anyway. I don't want to be a bottleneck, so I would say that the best would be to start a new common repo branch and rebase all our work on this branch, give a few people review/merging capabilities and based the work on the good will of people. I know that being alone and reviewing/accepting is a job that can get boring, as you also need to ensure the quality, splitting the responsibility here is desirable. Now, I do all the stuff there myself, but also I only have to check rock64/rockpro64 which is to be fair not a lot of hurdle for me, but with more dependence on this work we simply need more people.
     
    I somehow like the rebase workflow that we always keep a small number of patches, but I'm fine with merge workflow too