Jump to content

pfeerick

Members
  • Posts

    148
  • Joined

  • Last visited

Reputation Activity

  1. Like
    pfeerick reacted to tkaiser in Nightly images?   
    Ok: how to define a process to decide whether we want to support a new device or not?
     
    Current situation: a hardware vendor sends out dev samples worth 50 bucks and we waste our time worth tens of thousands of bucks on these devices without even starting a discussion whether it's worth the efforts or not. Or someone with commit rights simply adds a board since... no idea. That sucks.
     
    Can we agree on a process like https://forum.armbian.com/index.php?/topic/4451-example-support-proposal-for-rock64/ and if not what are your ideas?
     
    Current situation: We support way too much boards to deal with, we scare away potential contributors (IMO due to lack of clear communication and the feeling for 'externals' there's an 'inner circle' or something like that) and we always just talk and talk and talk but nothing happens. This also sucks.
     
    Using Armbian and having to fear an 'apt upgrade' really sucks. There was a lot of babbling about what has to happen prior to releasing major releases ('team testers' and stuff) but... today we're on 5.30 for whatever reasons (maybe I just missed discussion, call for testers and announcement?)
     
    If we're not able to test through all those boards we claim to support why do we provide upgrades that break the most important things? This is not the first time and if we don't start to think about why we update all the time without most basic testing more of these situations will follow. If we don't have the resources to test through every f*cking u-boot update every two months everywhere why do we roll out these updates? We have devices where u-boot is from 2013 or maybe even older and that's just fine. Using 'latest and greatest' without even testing is quite the opposite of the distros we put on top of this (horribly outdated AKA stable Debian variants). 
     
    This is how I would sum up Armbian engagement today: https://github.com/armbian/build/issues/512#issuecomment-269476270
     
    (sorry for this rant but I consider current situation extremely discouraging)
     
  2. Like
    pfeerick reacted to Igor in Nightly images?   
    OK, once per week and interessant only. I'll clear them out during this week. Will also push 5.30 updated images out.
     
     
    Fine with me.
     
     
    I made a third and I hope last adjustements. Now each one has it's own page, accessible from menu, below "Download". In /download, we only have stable, nothing else. I was only thinking to add links from there to WIP and deprecated section? Also some more explanation needs to be added to WIP and deprecated.
     
     
    Specific is to big waste of time for us ... no, perhaps some general infomation that users will understand get some ideas / hints, why we don't support just every board on the market and that shitty boards exits and there is nothing much we can do about.
  3. Like
    pfeerick reacted to tkaiser in orange pi zero reaches 85 degrees with heatsink!   
    That works surprisingly well even with zero airflow around. If you use the search function you'll find numbers.
     
    Wrt real topic: https://forum.armbian.com/index.php?/topic/4313-new-opi-zero-yet-another-high-temperature-issue/ (nobody uses search function here and nobody tries to nail the culprit down)
     
  4. Like
    pfeerick reacted to tkaiser in Not the usual ethernet problem on PINE64 (solved)   
    It would be nice if you adjust thread topic (adding 'Solved' to it) and edit your very first posting inserting a single line at the top descibing the problem 'switch fault, check your switch first' or something like that). Might save other people some time googling around...
  5. Like
    pfeerick reacted to winterflaw in Not the usual ethernet problem on PINE64 (solved)   
    It turned out to be the Cisco switch.
     
    Cisco make a range of SOHO products.  I can't speak very much for the products in that range outside of the line which I bought from, but I bought an SG100D-05 and it turns out they are basically, to quote one comment I read, "broken from the factory".  This is a far description, in fact.  The switch was loosing contact with the dev boards plugged into it (and needed to be rebooted) was unable to communicate normally with the PINE64.  There are plenty of other problems which you can find by Googling - including, for example (although I can't remember if it's my model or the ones in the next range up from this, the SSG220s) blocking all SYN packets on ports <= 1024 (which is staggering for an *unmanaged level 2 switch*).  I think Cisco never did release a working firmware which fixed the problem - a broken firmware came out after about two years...(!)
     
    If you're going to buy Cisco SOHO, make bloody sure you have a good Google first, because what you find will probably convince you not to buy Cisco SOHO.  That was surprising, of course - I *assumed* if it's Cisco, it's going to be solid kit.  It looks however like they just don't take the SOHO market seriously.
     
  6. Like
    pfeerick reacted to winterflaw in Not the usual ethernet problem on PINE64 (solved)   
    (One liner added later : the problem turned out to be the Cisco SOHO switch.  They're "broken from the factory".  Not what you'd expect, normally or in particular from Cisco.)
     
    Hi, everyone.
     
    I've taken the liberty of posting here with regard to my problem as I have the understanding the PINE64 forums proper are run by crazy people; my thought being to stay away from there.
     
    So, I have a 1 GB PINE64.  I have ethernet performance problems - but NOT, I believe, in any way related to the early production models with their hardware fault or with gigabit ethernet being flakey.
     
    My PINE64 is in fact connected to a 100mbit hub, and is as such running a 100mbit, not 1gbit, and it a fairly later model (as my original order was accidentally sent the wrong continent, and it took some time for this to be sorted out =-)
     
    I'm testing performance using nuttcp.
     
    This is a representative result;
    10.9375 MB / 1.00 sec = 91.7470 Mbps 0 retrans 11.2500 MB / 1.00 sec = 94.3755 Mbps 0 retrans 11.1875 MB / 1.00 sec = 93.8451 Mbps 0 retrans 11.2500 MB / 1.00 sec = 94.3732 Mbps 0 retrans 11.1875 MB / 1.00 sec = 93.8461 Mbps 0 retrans 11.1875 MB / 1.00 sec = 93.8466 Mbps 0 retrans 11.2500 MB / 1.00 sec = 94.3731 Mbps 0 retrans 5.1875 MB / 1.00 sec = 43.5160 Mbps 0 retrans 0.0000 MB / 1.00 sec = 0.0000 Mbps 0 retrans 0.0000 MB / 1.00 sec = 0.0000 Mbps 0 retrans 0.0000 MB / 1.00 sec = 0.0000 Mbps 0 retrans 0.0000 MB / 1.00 sec = 0.0000 Mbps 0 retrans 0.0000 MB / 1.00 sec = 0.0000 Mbps 0 retrans 0.1875 MB / 1.00 sec = 1.5729 Mbps 0 retrans I've tried changing the cable and I've tried changing the port and I've tried changing the power supply (I have a USB multimeter, and the load is fine - much less than the 2 amp the socket is rated for).
     
    I also have a Raspberry Pi 2 and a Createo Ci20 plugged into the same hub, and they work fine - the Pi shows a consistent 93/94, with no drop outs, the Ci20 about 70 (which is also odd, but seems to be the way it is on that board).
     
    I also see these results on the PINE64 on the Debian distro.
     
    Googling for other people's experiences is hard because you can't get away from all the posts about the gigabit ethernet problems.
     
    Does anyone have any advice?
     
     
     
     
     
     
     
  7. Like
    pfeerick reacted to tkaiser in ROCK64   
    ROCK64 product page online with links to various resources/documentation: https://www.pine64.org/?page_id=7175
  8. Like
    pfeerick reacted to zador.blood.stained in Quick Pinebook Preview / Review   
    As I said, I personally won't touch suspend/resume at all (on the legacy kernel) unless ARISC firmware sources are provided, but I'll try to fix other issues if I can.
    Lid switch works in the kernel (there is an input device that sends events on lid open/close), so this just needs propagation to the power management suftware (upower, systemd-logind, ...)
  9. Like
    pfeerick reacted to zador.blood.stained in Quick Pinebook Preview / Review   
    Regarding backlight control issues:
    Jun 06 15:41:31 pinebook pkexec[3562]: zador: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backlight-helper --set-brightness 51]  
  10. Like
    pfeerick reacted to zador.blood.stained in Quick Pinebook Preview / Review   
    No idea why defaults are there as they are, but brightness is controllable after editing /usr/share/polkit-1/actions/org.xfce.power.policy, so we should add an override for this file somewhere (in /etc?)
     
    Edit: fixed
  11. Like
    pfeerick reacted to bozden in New OPi Zero - Yet another high temperature issue...   
    Yes, that is what I wrote to OPi forums. I think the point they have is "we boosted it, cool it - or underclock it to reverse". The Zero's were already hot and they made them hotter. Not suitable for summer projects  
     
    I never used WiFi on these boards yet as I read about the performance in your tests.
    I'll test them whenever possible with similar setup like your tests. I'm working with OPi One's now and I have to finish them first.
     
  12. Like
    pfeerick reacted to tkaiser in Quick Pinebook Preview / Review   
    Tested without issues on 14" Pinebook, PR merged already. Do we need a patch for the same set of changes for u-boot too?
  13. Like
    pfeerick reacted to zador.blood.stained in Quick Pinebook Preview / Review   
    Looks like u-boot may use this value, so we can change the DT there too just for the consistency, even though static boot logo should not expose any tearing issues.
  14. Like
    pfeerick reacted to zador.blood.stained in Quick Pinebook Preview / Review   
    OK, so we need to test these values on 14" and if it works fine then this can be considered as fixed.
  15. Like
    pfeerick got a reaction from zador.blood.stained in Quick Pinebook Preview / Review   
    Ok, I can also confirm on my 11" pinebook that changing reduces the tearing and gets rid of the bottom row of dots... it isn't interlaced like it was before, but I think it is still there a bit, but that may be a artefact of XFCE not liking window contents being shown when dragged (easiest way to spot) and not knowing how much we can push the lcd_dclk_freq without something going pop. Interestingly enough the reported screen refresh rate jumps from 60hz to 64 hz. Changing the lcd_ht and lcd_vt then drops it back to 56hz like we usually see on ayufans mate images
     
    2180c2249 < lcd_dclk_freq = <0x48>; longsleep --- > lcd_dclk_freq = <0x4d>; ayufan 2187c2256 < lcd_ht = <0x5dc>; longsleep --- > lcd_ht = <0x640>; ayufan 2190c2259 < lcd_vt = <0x320>; longsleep --- > lcd_vt = <0x35c>; ayufan  
  16. Like
    pfeerick reacted to StuxNet in armbian-config   
    How I know that feeling. Totally understand, my bad. Keep up the good work man.
  17. Like
    pfeerick reacted to zador.blood.stained in Quick Pinebook Preview / Review   
    OK, but it will be low priority for now since we have screen tearing issues (should be fixed by modifying the DTs according to the Pine64 IRC logs) and I have shutdown/reboot issues and no logo at all on Armbian builds (so will have to make a serial console adapter to see what's going on)
  18. Like
    pfeerick reacted to zador.blood.stained in Quick Pinebook Preview / Review   
    Quick update:
    no support bmp picture without bpix 24 or 32  
  19. Like
    pfeerick reacted to Xalius in Quick Pinebook Preview / Review   
    I have not heard back yet from TL regarding XPowers looking into the issue with the battery charger, and I pretty much would like to see the ARISC code by now since working around that black box is rather frustrating. For now I changed my UPower settings to shutdown at 4% and the default action to 'poweroff' instead of 'hibernate' to avoid issues...
  20. Like
    pfeerick reacted to zador.blood.stained in Quick Pinebook Preview / Review   
    What do you mean by "too large"? File size? Default is 3MB, if saved to 256 colors it's 1MB without noticeable quality losses. I would prefer to use this as a boot logo too.
  21. Like
    pfeerick reacted to zador.blood.stained in Quick Pinebook Preview / Review   
    This was done already, now we need to make images and place them in /boot directory
  22. Like
    pfeerick reacted to ecolezen in Pine64 - System (Booting Up) LED   
    Hi, sorry for the delay... I did something wrong on forum setup because I am NOT receiving notifications...
     
    As for my incarnation of the Duend Grenlins, he decide in this order:
    a- Debian base fail for 2 SDCards, 2 Power adapters and 2 different monitors...
    b- Xenial also fails somewhat for the same combinations...
     
    c- Armbian boot OK in the very first attempt... !!!
     
    But lets be correct and fair, because I am going to use ALL images, and ALL effort that is being done I consider valid and important, so that, in the end, it can agglutinate to a large body of knowledge and strong platforms with choices for us to use for any kind of application...
     
    After all, variety and choices is one of the great things that ARM SBCs is creating...
     
    Valter
  23. Like
    pfeerick reacted to Igor in Quick Pinebook Preview / Review   
    I also does not experience any screen tearing with our build. There was some in system on eMMC, one of the first Ayufan's builds.
     

    Some small rework of u-boot will be needed for that but I guess its doable. But first I wanted to solve "going to suspend when lid is closed". I think it's some xfce related issue, since lid driver is present and working, manual suspend also work, ...
  24. Like
    pfeerick reacted to tkaiser in OMV image for Orange Pi Plus 2 EMMC   
    Nope, this is not SATA here but the most crappy USB to SATA bridge found on any device.  Please do a web search for 'crappy GL830' for details.
     
    Of course not, boards with GL830 aren't suitable for NAS purposes and should be avoided.
  25. Like
    pfeerick got a reaction from ecolezen in Pine64 - System (Booting Up) LED   
    Yup, that makes perfect sense... the SBC equivalent of a blinking LED in Arduino / micro-controller, or the infamous 'hello world' program!  
     
    I would have suggested you go with the Ubuntu Xenial images that longsleep maintains instead of the debian ones... they start off stupidly small, and should also have 'just worked'... there have been more than a few issues with the Debian images. They're not immune to the odd gremlin, but Simon does try to work out the underlying problems if he can reproduce the symptoms.  
     
    2GB Class4 SDCard? l see you're asking for a world of pain and slowness!  But a good point still!  
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines