pfeerick

Moderators
  • Content Count

    146
  • Joined

  • Last visited

Reputation Activity

  1. 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?
  2. 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.
  3. 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.
  4. 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  
  5. Like
    pfeerick reacted to StuxNet in armbian-config   
    How I know that feeling. Totally understand, my bad. Keep up the good work man.
  6. 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)
  7. Like
    pfeerick reacted to zador.blood.stained in Quick Pinebook Preview / Review   
    Quick update:
    no support bmp picture without bpix 24 or 32  
  8. 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...
  9. 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.
  10. 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
  11. 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
  12. 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, ...
  13. 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.
  14. 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!  
  15. Like
    pfeerick reacted to hmartin in The new Banana PI M2 Ultra   
    While I agree that it is not our job to provide support to people buying the boards (that would be the manufacturer's responsibility) if someone wants to add support for the board in Armbian I don't see why we should refuse their help.
     
    Of course I have zero sympathy for people who come here and complain about the hardware decisions the vendor made (e.g. microUSB power, crappy EMMC, bad 1T1R WiFi) because that is entirely outside our control.
     
    So I would say, if someone does submit patches to support the Banana Pi M2U or Berry, we accept it. But it is also wise to put up a disclaimer that any images for Banana Pi come with zero support and we will ignore requests for free support on the forums.
  16. Like
    pfeerick reacted to zador.blood.stained in Nightly images?   
    Well, we don't exactly ask for "useful feedback".
    Most of the problems reported currently are for unsupported/development configurations and those problems are known already.
    For problems reported for supported configurations - sometimes it helps, especially when logs are provided, and especially for new boards or after bumping u-boot and/or kernel versions.
    Also we have assigned beta testers, so IMO we still need nightly images (unless we want to encrypt .7z files with passwords available only to beta testers )
  17. Like
    pfeerick reacted to zador.blood.stained in Nightly images?   
    IMO this needs to be discussed separately, not in this (Banana Pi M2 Ultra) thread.
  18. Like
    pfeerick reacted to Igor in Opi Zero MAC address issue on Mainline kernel   
    Mainline = experimental, no support. Network driver will be changed.

    Armbian support feels like a bunch of parrots each time one of those questions from experimental area pops out 

  19. Like
    pfeerick reacted to tkaiser in Armbian ver 3.* failed from build tools   
    I highly appreciate you doing this and I'll also invite you to become moderator of 'Random Ubuntu flavours as build system chaos' subforum. You should keep in mind that you'll soon deal with important questions like 'Why is Linux Mint not supported?! It's based on Ubuntu!!' and 'What about Bash environement for windows 10 with xenial distribution' and other ways to deal with everything that smells like Ubuntu. Of course you should first test through all 22 linux families currently supported with all kernel and u-boot variants (that's the funny thing with that: we have some combinations where u-boot needs GCC below 5.4 in 32-bit while the kernel only compiles with 64-bit GCC 6.1 or above). Of course you also need all boards to test through (maybe a Kickstarter? The few hundred bucks for the hardware aren't the problem but your new full-time job will be)
     
    Maybe that's already enough to understand that this 'very little time' is better spent on real improvements? Besides that we recommend a virtualized environment for OS images for a single reason (not mentionend anywhere yet except forum): If there's ever just a little error when dealing with image creation (happens as root using dd and trying to overwrite sectors of the image) the build system can overwrite your whole OS or at least renders it unbootable!
     
    The main reason people like to use something else than Ubuntu 16.04 is that they already run something else that's Ubuntu-ish. And that's bad and should be avoided. So forcing users to setup an own virtual machine wit 16.04 is already fighting lazyness and preventing a mess if something ever goes wrong.
  20. Like
    pfeerick reacted to tkaiser in Armbian ver 3.* failed from build tools   
    [x] done.
     
    @ssuloev: BTW: I didn't want to be offensive above. Just give the other devs the idea that 'trying to be friendly/polite' is sometimes wrong. Overreading/ignoring warnings is just human (even providing partially wrong information when requesting support) and if recommendations turn into requirements (as it's the case with 'Ubuntu 16.04 only' now) then we should switch warnings into errors too. Saves everyone time and hassles.
     
    And also we should rethink answering questions in the forums. Now we have an infrastructure where commits below https://github.com/armbian/documentation almost immediately show up on https://docs.armbian.com. So when questions arise we should think twice about why (eg. 'why 16.04?' Nowhere answered below docs.armbian.com but multiple times in the forum) and then prefer to commit an unstructured entry to a yet not existing developer and user FAQ, wait until it shows up over at docs.armbian.com and then post a link to it?
  21. Like
    pfeerick reacted to martinayotte in Armbian ver 3.* failed from build tools   
    Yes, Zador is right ! We shouldn't "trash" the WIPs, but simply hide them and make them visible with EXPERT=yes.
    Otherwise, it will be a pain even for experts ...
     
  22. Like
    pfeerick reacted to zador.blood.stained in Armbian ver 3.* failed from build tools   
    We may still want those to be accessible for internal testing purposes, so hiding "Show WIP" button (unless, for example, EXPERT=yes hidden option is supplied) may be a better solution
  23. Like
    pfeerick reacted to tkaiser in Armbian ver 3.* failed from build tools   
    IMO the only way to deal with situations like this (Armbian developers not developing anything useful any more since only being trapped in unnecessary first level support situations).
    Documentation mentions that only 16.04 is supported build environment (14.04 was ok for kernel only compilation but that has been removed now too). You use 16.10, get a warning that 16.10 isn't supported, ignore this warning (you had to press [enter] to confirm what you do), fail as expected and ask for support (you confirmed before to not do this) now telling us you would use 16.04. Since 16.04 is the supported environment Armbian developers try to solve the problem (hunt for a bug) and look into your logs just to realize that your claim to use 16.04 doesn't match reality And then they also waste their time to explain why our recommendations are not written just for fun but to guide developers and trying to save both external devs as well as Armbian core team members from wasting their time on well known issues @Igor and @zador.blood.stained: what about immediately trashing the .wip files for crapboards now to focus back on important stuff?
  24. Like
    pfeerick reacted to tkaiser in wrong access rights for dpkg-deb after U-Boot build   
    There has never been a 'LeMaker M2' and SinoVoip's M2 has no Mali but PowerVR instead (with this M2 neither 3D nor video acceleration works). If you were talking about M1 instead I fear you either don't care that much about details or missed that two different SoCs are WAY MORE IMPORTANT than a stupid hardware vendor trying to sell all his ABSOLUTELY INCOMPATIBLE boards with a similar name. Those Banana morons today sell M2, M2+, M2 Ultra, M2 Magic and soon also M2 Berry. Only Berry and Ultra are somewhat compatible since the Berry inherits shitty software and support situation from Ultra but will cause even more problems due to crappy Micro USB for DC-IN.
     
    M2 = A31s, M2+ = H3, M2 Ultra/Berry = R40, M2 Magic = R16 (which is an A33 in reality, we're dealing with here even with 'marketing by obfuscation'). There you go as @zador.blood.stainedalready outlined: http://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix
     
    If the Armbian project wants to focus on something relevant we should stop supporting crappy hardware. But that's obviously just me and others seem to love threads like this.
     
    Edit: My definition of 'Armbian project' was being the bridge between kernel developers and end users. Caring about settings and details, spending an insane amount of time on research/testing and optimizing details, collecting patches, assembly everything to an easy to use OS image that ships with sane defaults (performance and security) and receives upgrades. This was never about providing shitty OS images people can complain about (since this and that doesn't work yet but users don't want to understand -- that's the 'nightlies' situation currently. Now it seems if we don't provide nightlies for reasons for a board users expect to be somehow related with Armbian users start to mis-use the build system to try to create shitty OS image with it on their own. And ask even for support if they fail. And we even try to deal with this over and over again instead of re-thinking the whole approach)
     
     
  25. Like
    pfeerick reacted to zador.blood.stained in wrong access rights for dpkg-deb after U-Boot build   
    For some reason you ignored @tkaiser's words
    and still are complaining that the image doesn't work.
     
    First steps in developing for R40 and Armbian - go to https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix and wait first until R40 column appears in the table and then wait until at least third of the cells for it are marked light green and another third is marked bright yellow. Experience with other images on M2U or images on other boards certainly doesn't matter here.
     
    That I still don't see a serial console log which is a prerequsite for saying that something "doesn't work" or "nothing happens", especially for targets marked as WIP.
     
    And instead of doing release preparations we now have to think about putting extra dialogs and warnings for WIP targets and hope that this will help with avoiding wasted time with support requests for them.