• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    suberimakuri reacted to sfx2000 in RK3328 Kernel   
    Hmm... actually yes - is the role of Armbian to teach users about Linux? Probably not, IMHO, they're better served by the Pi Folks - Raspbian is good training wheels for folks dipping their toes into Linux
    The average Armbian user is not a paying customer - there are no Service Level Agreements dictating that any bug of a defined severity level must be fixed within a specific timeframe.
    So yes - just ignore it for the most part, step in if is sounds fairly interesting - sounds a bit mean spirited perhaps, but generally folks will step in to help out, and if it's really a bug that is directly traceable back to Armbian code - then if it pops up enough, fix it directly, or delegate it to someone who is maintaining it (better to delegate, as that person knows the code likely better).
    So if someone has problematic hardware - "my whoflungpI Zero2W with the built in XYZ WiFi adapter doesn't work" - well, it might be crap hardware, and in the sub-$50USD field of hacker boards and TV boxes, there's a fair amount of crap - can't fix bad hardware, and there, someone will tell them, use something that does work.
  2. Like
    suberimakuri reacted to Igor in RK3328 Kernel   
    True. Larger developers community is the reason we are getting somewhere in the first place. I am aware of that. Also groups around projects helps to achieve more and less work is doubled, tripled ... but relationship between creators/contributors and average users, "I am new to Linux", support is rather extreme even without dealing with Raspberry Pi herd.
    User: I am (also) reporting that functionality X is broken. (they have no idea that this "small bug" might represent a project worth months of work)
    Two days later.
    User: Hey, have you fixed this?
    If "user" would be my paying customer we would terminate the contract right away. Sadly I am seeing such daily and that's why I am upset. How to deal with this and how to do it less personal way? Just ignore?
  3. Like
    suberimakuri reacted to TonyMac32 in RK3328 Kernel   
    Sigh...  My guess (entirely guessing, I have not looked yet), is that we or Mainline fixed the Rev 3, which broke the Rev 2.  I am not entirely pleased at the significant hardware changes made by Pine in this case, it is causing problems...
  4. Like
    suberimakuri reacted to lomady in RK3328 Kernel   
    Sharing a bit of feedback:
    I tried nightly buster minimal build with 5.3 kernel for Rock64 rev2.0 and it does not reach the state when it is accessible over the network. Both LEDs on the ethernet connector are off. I did not connected the HDMI display and moved on to other things.
    Hope this helps.
  5. Like
    suberimakuri reacted to vlad59 in Start looking at 5.3.y   
    I finally found where I read about problem on some pine64+ for ethernet, it was in Librelec forums and Jernej added a patch fixing that a few weeks ago :
    The last part of the patch is interesting (= could fix my problem) and was queued for kernel 5.4 :
    Grepping for `config-magic-for-pine64` or `regulator-enable-ramp-delay = <100000>` inside armbian build source return nothing so I guess that can be it.
    I'll try a dev build with this patch tomorrow and report here either way.
  6. Like
    suberimakuri reacted to jock in Start looking at 5.3.y   
    Hello, I managed to bump the rockchip-dev kernel to 5.3.y on my fork. After removing a couple of redundant patches and updating two or three of them I'm able to compile with no problems. The new kernel also boots fine on my rk3288.
    Don't know if anyone is already working on this (maybe @Igor or @TonyMac32), if my work can ease someone's else fatigue I can make a merge request from my repo to main armbian repo for code review (the single commit is here) documenting the steps I did.
  7. Like
    suberimakuri reacted to TonyMac32 in RK3328 Kernel   
    @jpegxguy  For the mainline ethernet tx/rx delays, were those just copied from the Rock64 or were they empirically determined?  They're caused by trace impedance/etc, so they're tied to the specific hardware.  I'll dig up the thread/tool Ayufan and Tkaiser were using and see what I get, there might be some more to gain there, since obviously the default ones are fairly bad.
    @Igor Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"?  I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline.
    [edit]  Fixed the lower USB port on Renegade.
  8. Like
    suberimakuri reacted to TonyMac32 in RK3328 Kernel   
    ____ _ | _ \ ___ _ __ ___ __ _ __ _ __| | ___ | |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \ | _ < __/ | | | __/ (_| | (_| | (_| | __/ |_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___| |___/ Welcome to ARMBIAN 5.76 user-built Ubuntu 18.04.2 LTS 4.20.13-rockchip64 System load: 0.02 0.17 0.11 Up time: 8 min Memory usage: 14 % of 1998MB IP: CPU temp: 48°C Usage of /: 12% of 15G [ General system configuration (beta): armbian-config ] So that works, although missing a USB port (bottom USB2 is not with us).