Jump to content

pfeerick

Members
  • Posts

    148
  • Joined

  • Last visited

Everything posted by pfeerick

  1. That's right... it looks like it's taking into account the buffers, shared and cached memory. Before I can break it down, can you give the output of free -w, as it displays it slightly differently. if you can get the motd in shot that would be great also, as it would let me confirm the maths I'm off to bed now, so it will be a while before I reply To give you another example for comparison:
  2. No worries, I'll remove it (actually, I think another mod beat me to it!). Please do report back and let us know how you go. And someone else might post in the meantime with more info or more ideas.
  3. As a general lurker, and out of the loop outsider... I think this is at the heart of a lot of this discussion, and is a really good idea. Keeping that format, new thread for a new board proposal, top post giving the overview, current status, links to noteworthy posts, etc, would be a good thing. It ensures that everyone is on the same page, and knows what's going on. And if it is decided that the board should the EOL'd and shelved, it can become it's tombstone and rationale for why it was EOL'd. that's my 2c anyway
  4. I would suggest that you look at getting a different power supply, as mobile phone chargers are notorious for being unreliable for SBCs. They tend to either not provide their full current until the phone has *handshaked/negotiated* with the charger, are noisy, or drop their voltage they are loaded to below usable levels (as phone charging needs aren't that demanding). I would suggest you look at getting something like the white power supply (with interchangeable international plugs) for the raspberry pi. Also, please refrain from making multiple posts... someone *will* reply eventually
  5. @Dariusz Biernat I doubt it, since Ubuntu is a simply a derivative of Debian anyway I think he simply meant that on a debian base, change to the testing release branch on order to get a (recent) build of Chromium. On Ubuntu there is no need as the whole idea of Ubuntu is it is closer to the bleeding edge.
  6. Not naming names. But rest assured it's no-one from this forum. And you just *know* I want to remove the 'n' from your post, don't you! :-P Thanks Zador. I decided I'll just lurk for a couple of days to see what the flow of things are, and will simply approve stuff if I see it in time! So that would be Warning -> Spam -> Restrict from posting content? Dangers of moving away from a dictatorship :-P I know a link would be nice, but would a simple "This post has been split... go find it yourself" (slightly more diplomatically worded, of course) suffice to not mess with unread flags??
  7. No worries there... I only edit when it's some thing silly like those quote-within-quote-within-quote posts (which don't seem to happen here), or code formatting hasn't been used. Basically readability stuff, and I make it known that is why the edit was done. And point taken, all hail the mighty Igor! @Igor When it's obvious human spam, do we temporal ban or just kick? Case in point: jessica951 Just want to ensure I toe the company line!
  8. I'll bite. I did say I was willing to help out any way I can. If it means spam control, so be it! And thanks for the link to the article... I'll have to ram that down the throat of another "moderator" that I know someday...
  9. @Igor Just putting my name down here as willing to offer whatever support I can re: testing beta images and bug squashing for the boards I have (list in signature). I can't promise I can fix any problems bar minor ones or the glaring omissions that occur due to starting at the code for too long... but I will try anyway. For me this is fun... new challenges
  10. Confirmed. I did this just last week with two Orange Pi Zeros. DietPi "more" adaptation was to put menus on stuff which are nice for a novice, but also restrictive if you only stick to the menus. Then there are gaping security holes, and questionable hard-coded design choices. But hey, it works for some people, so I won't knock it too much! I'd just prefer to start from a solid base, and work my way up knowing that it won't come back to bite me later!
  11. Thanks tkaiser. I'll leave the u-boot patch to you guys (I'm guessing zador?)... I have absolutely no idea where to start on that one... other than guessing that a diff patch needs to go in https://github.com/armbian/build/tree/master/patch/u-boot/u-boot-pine64-default ?? But a diff of what... I'll wait for the commit and work it out then Two things I noticed in the latest build: I get the boot logo now from uboot, but it vanishes as soon as the kernel starts up... or is that expected? The LCD brightness doesn't seem to be able to be adjusted via the power management applet in XFCE.
  12. 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
  13. Drats... was hoping I'd have those patches already as I was using the nightly from... maybe a week ago? Anyway... I'll run a self-build of the current master in a few minutes and see what it's like. @zador.blood.stained: Edit: One remaining question... I get the boot logo now, but it vanishes as soon as the kernel starts up... normal? and rest doesn't apply Did you check the display settings by any chance? Does that one line also influence the screen refresh rate? I know Luke and I keep harping on about that... but it seems to be a common factor so far... screen refresh rate drops from 60hz to 56hz, funky bottom line of pixels (green or line of red blue green depending on how close you look) goes away, and tearing isn't so obvious on the 11" with horizontal movement of objects on the screen.
  14. Since you're looking at the BMP stuff... any pointers or a link to some docs explaining what command (maybe a imagemagick convert cmd?) I should use to create/convert a compatible BMP for uboot? Either I fed it the wrong format, or ... oh wait, you just committed a change that explains part of it... the paths being wrong for the charge related BMPs anyway. I tried using the bootlogo.bmp from tkaiser's commit, and shoved it into the root of the microSD, but it still didn't like me... I think it said 'not a BMP' or words to that effect... so I'll look again in the morning... I gave up it for the night once I decided to give up and just use the commit BMP and that didn't work for me. And yes, have to look into it further but there is definitely something in the DTS that is causing it... ayufan pointed out one promising line... the lcd_clock, but have to investigate further...
  15. Yeah, I was going to say when I saw the list of four images needed why not just re-use the battery ones that are already in use... I also prefer the blue pinecone armbian logo... looks very slick. When you say too big... are you meaning file size? 3MB being too big for the time that you see the logo?
  16. For what it's worth since this is a nightly development build, I can also confirm this on the 5.27.170529 nightly on my 11" pinebook. The bottom line isn't green for me though... its a one pixel high line of green-red-blue pixels (which repeats for the entire line), but does sort of look like a green dotted line at the right distance. And yes, screen tearing is present also. Interlaced screen output perhaps? Performance seems good though, and it starts up very fast even from a not-particularly-fast microSD. WiFi connected without any issue, haven't tried bluetooth but no reason to suspect it doesn't work. I also like how the network connection is dropped before the system suspends, making sure the network-manager refreshes when the system resumes. Since there's no fat boot partition (which is great as it won't stuff things up as far as system updates), is it going to be possible to add a boot screen and possibly the charge indicator/power on reason screen, or is that likely to be in the too hard/unimportant and unnecessary frills basket?
  17. My apologies if I'm taking liberties by butting in here, but as a outside observer just starting to fiddle with Armbian in a more than lets-download-this-random-image fashion, but starting to look at the code and how all the scripts fit together, and using the build system, perhaps what you need is nightlies which are protected in some fashion, then beta / pre-release images. Thus the nighties don't get used by us ignorant needy users, and you can still access the nightly builds. And then when you feel the nighties are stable enough for 'public consumption' you flip it to the beta line... so three tier... nightly, beta, release. And anyone who wants a nightly image can suck it up and go download the build system and compile it themselves. Having support for vagrant takes all the argument out of "why doesn't it work on *insert-random-linux-flavour-here*" and "but I don't know how to compile it". You guys are wasting enough time as it is on these questions... so something needs to be done to put the checks and balances in.
  18. It would be best to wait until the OMV Armbian builds are officially supported. They are still in a pre-release state, and obviously tkasier hasn't gotten around to testing/compiling for the Orange Pi+2 (if he indeed intends to! ). So you can either wait for that, or try building it yourself following the instructions on how to build the OMV images yourself, and see what your mileage is, and perhaps you could also report back on how well it works for you as some feedback also. It might work out of the box... it might not. As it's still in a preview state, I wouldn't be expected anything any-time soon. Wanting, yes, expecting, NO!
  19. Would just like to bump this topic, as I'm wondering if there is anyone who knows how to, or has managed to get around the "Unable to find free loop device err" or the "mknod: /dev/loop0: Operation not permitted" errors?? As far as I can remember, this only becomes an issues when doing a full image... due to the use of debootstrap. As the OP has pointed out, the --capability=CAP_MKNOD appears to have no effect. This was on Ubuntu 16.04.2 / x64.
  20. @AdFad666lol.... why doesn't that surprise me? WSL is a toy at best at the moment... it's fun to play with, but is missing too much stuff for usage. VirtualBox + Ubuntu still trumps it for linux on windows that actually works! To the OP, in the spirit of helping you resolve your issues, I ask this: Have you tried ensuring that your hyper-v (hiper-v???) linux build environment is running 16.04. If not, please do so. To not do so will simply result in flame threads like these, because you didn't read the most basic requirement which is that the build environment must be ubuntu xenial / 16.04, due to compiler versions and known compatibility. Vagrant may also be another option for you... there is a Vagrant config file distributed with Armbian which works great on Linux (and even a readme guide you can follow) and I presume would work on Windows as well as Vagrant is available over there, and uses Virtualbox under the covers to provide the guest OS emulation. If you or anyone else reading this happens to use Vagrant on linux to simple provide a clean build environment, make sure you download the package files from their website, and not use the ones in the software repositories, as they are out of date, and the disk resize plugin won't be installed properly. I've also run Armbian image builds on my native Ubuntu 16.04, and didn't have any issues whatsoever there, so that does indeed work flawlessly. I tried systemd-nspawn, and IIRC it compiled kernel packages fine, but bugged out on trying to do a image build due to loopback device issues. And the workarounds don't seem to work any more, so I wouldn't recommend it. I was going to try docker, but didn't like the fact it resets the build environment back every time you shut it down, so I would have to fiddle with that further to see if I can get it to co-operate best.
  21. Oh my... you should make a mod of the 'Random Ubuntu flavours as build system chaos' sub-forum as well... at least I can guarantee zero results as I'll do absolutely nothing but say "Use 16.04... the Armbian devs chose to base off a LTS build for a reason". You foolish devs... what will you require next... that all 'aspiring devs' should actually compile stuff on an actual computer instead of one drawn on paper? :-P And why for the love of god is Windows Subsystem for Linux not supported... I mean... what can go wrong? A crappy linux emulation running inside a crappy microshaft os? They've only just recently added support for mounting external drives in the linux subsystem... what's not to love hate? Right... even I've wandered in and said something... someone should lock this thread soon before this gets absolutely loopey and bat-shit crazy. Hell, I can't get ayufan's jenkins/docker builds to work for the pinebook images, but at least I didn't turn around and say "thou must make it work for me because it can't be a PBKAC"... I've kept fiddling, and will be contritely asking soon "wtf am I doing wrong here". I haven't tried the armbian build system yet, but I'm sure I can screw even it up somehow... but I'll at least read the warnings and follow them!
  22. I was just looking at that again because of another post, and noticed that on line 66 $capacity is lowercase, and on line 73 it's uppercase ($CAPACITY)? Aren't shell script variables case sensitive? Thus making it so the 8GB condition never fires???
  23. This NOT an etcher bug. A small image is written to a big (micro)SD card, and it is then resized on the first reboot. Sometimes there is a automatic reboot, other times it is left up to you. I believe it is something to do with whether resize2fs can do an online resize or not on different kernels?? (you can see the test here in the resize2fs script). When you logged into the CT for the first time, it probably have had the red text shown on this screenshot (which obviously for a OrangePi Zero, but never mind...). As the text indicates, and as Igor said... reboot! If you manually reboot and the file system hasn't been expanded... then there is a problem!
  24. Hey @tkaiser... just so you know... the final v1.0.0 of Etcher removes the CRC as a *feature* of their dynamic end page. :-/
  25. Yeah, that's what I'm hoping we can do. I listed the part number in the desc on flickr, but didn't have any luck finding the datasheet, so hoping either TL can provide it, or someone else has luck finding it. I was thinking about bypassing the protection circuit, but it obviously was needed as something went wrong and the AXP didn't kill the juice. So I'd prefer a temperamental battery to a dead battery. Hopefully they add a bypass button in the future so that you can simply pop the back cover (or poke a toothpick through a hole) and plug in the power, and it should then be good.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines