pfeerick
-
Posts
148 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by pfeerick
-
-
Only other thing I can suggest is maybe the microSD is corrupt or faulty? (yes, clutching at straws with my limited knowledge
) If you can try re-writing the Armbian image using Etcher. And please keep in mind this warning from the download page: "All currently available OS images for H5 boards are experimental". I would be surprised if the images were that unstable that they wouldn't even boot, but the warning still stands... murky waters ahead!
Other than that, I'll have to bow out and leave it for more experienced folks to chip in
-
Great posts @chwe! I have been meaning to get my OPi Zero up and running for MQTT duty, and this post pulls together both the ESP8266 and NRF24L01 stuff that I wanted to use with it! And now I have a reason to finally use node-rode... I didn't realise it would make that nice dashboard! Thanks!!!! And this link just cracked me up... nice!
To call me an IoT expert is like someone call[ing] tkaiser a fan of micro USB powered SBCs.
-
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:
-
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.
-
14 hours ago, tkaiser said:
If there would have been a rather clean 'board bring up' thread such findings would have been documented (adjusting post #1 in the respective thread), board support rating would have been adjusted and post #1 of the thread could act as something like a landing page for the specific device (moderators pushing newbies to this 'page' for example).
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
-
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
-
@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.
-
11 hours ago, martinayotte said:
Is it the one we all know
n?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
13 hours ago, zador.blood.stained said:If it's an obvious spam - just use The Banhammer, full swing, straight to the head (aka "Flag as spammer" function).
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?
4 hours ago, Igor said:We have dispute in less than one day ?
When moving, leave a pointer - it deletes auto in 30 days.
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??
-
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!
-
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...
-
@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
-
3 hours ago, Igor said:
Anyone can try and confirm this - you are doing something wrong.
Confirmed. I did this just last week with two Orange Pi Zeros.
3 hours ago, Igor said:Their "more" adaptation of Orangepizero is exactly zero.
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!
-
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.
-
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
-
14 hours ago, tkaiser said:
You need latest u-boot with @zador.blood.stained's patches: linux-u-boot-pinebook-a64_5.27_arm64.deb.gz
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. -
2 hours ago, zador.blood.stained said:
Quick update:
no support bmp picture without bpix 24 or 32Since 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...
-
8 hours ago, tkaiser said:
Wrt our boot logo my favourite was bootlogo-armbian_blue_1365_767.png from http://kaiser-edv.de/tmp/NumpU5/ but in the meantime I think it's too large.
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?
-
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?
-
7 hours ago, zador.blood.stained said:
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
)
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.
-
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!
-
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.
-
@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.
-
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
lovehate?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!
-
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!
IoT with an OrangePi Zero: Node-Red + Mosquitto + ESP8266/NRF24l01
in Reviews, Tutorials, Hardware hacks
Posted
lol... it wasn't needed, but is appreciated (I could have just used my super cow privileges and edited it you know! :-P )...
Indeed. Knowledge is something we have learnt from the community around us, so it is only right that we shared it... we didn't 'create it from a vacuum' after all
. And what's wrong with a good toilet sensor... although I'm not sure it makes sense to detect when toilet is running (sorry, couldn't resist). My use case is lest sophisticated atm... good 'ol weather logging... but if I get it running how I like it, then who knows... maybe it'll become a bit of home automation... turn on the lights, that sort of thing...
Only good thing I got from mysensors so far was a link to a nice DIY atmega328 nrf sensor node board, with screw-header expansion option... was much neater than my breadboard to breadboard PCB version
. That and from the same author, a nice nrf -> rpi header adapter module. I have yet to go near their abomination of a codebase (it can't be that bad, can it?) ... wish me luck! 