pfeerick

  • Content Count

    146
  • Joined

  • Last visited

Everything posted by pfeerick

  1. @Igor I've edited both announcements a bit, see what you think of the changes. And please, please, please change "Before you think to report a problem with your board running Armbian' to something a little less... sharp? I know I would do that tongue in cheek (and do... hence why you sometimes see strikethroughs in my text) , but that could be a little less unfriendly... "Before reporting problems with your board running Armbian" or ""Before reporting problems with your board running Armbian, check the following" ... something like that?
  2. @prahjister Have you set up Avahi on that image? Just wondering if something like http://octoprint.local would work with your image, making IP addresses not necessary? Otherwise it's probably either setting a fixed address on your router, using (sudo) nmtui to configure the connection (assuming network manager is managing the connection) or some ugly /etc/network/interfaces edits.
  3. @Yuan I can't say I'd agree with that voltage... I think it's a little too high. 5.3v is the highest I generally go at the power supply. Keeping in mine the USB spec tolerances of 4.75V-5-25V, so if the 5v rail is also providing the USB voltage (and it often does), you're in danger of pushing a higher voltage than what devices are expecting, unless you get enough of a voltage sag over the leads. Whether that is enough to blow up a USB device when you plug it in, I couldn't say as I haven't tested every device under the sun. However, I would expect it to shorten the live of some devices. What
  4. That was what I was proposing... sort of. I fully understand due to different board configurations and architectures that board specific methodologies are too varied and complex, assuming all the information needed is exposed. I was thinking the cpuburn type task, coupled with a token, so that say if the system does that sort of power on b0rkage that after a couple of cycles it could let up and basically tell you your power system is broken. Because end-less boot loops aren't user friendly either. Part of the the change in thinking that is needed here is acceptance of the fact that a lot of pe
  5. Done. I had been avoiding this as I didn't want to edit the original post (in the new split thread) which was the only way I know of to contextualise the thread on this forum system. However, I've done that, and the new thread is here. I think I've pulled all the more board specific posts out, leaving this thread to focus on the proposal.
  6. Sorry about that, I only just caught up with the thread, so I didn't many to reply to that before now. Hm... first boot checks? Do some basic 'has the user used a crappy or faulty SD card, or using unreliable power (i.e our old favorite microUSB with a phone charger) at first boot, and basically say... if you continue past here, don't come near the forum or expect support? And have a reminder as part of the MOTD of this flawed configuration? If that essentially what you are proposing, I second that. But I'm not part of the inner circle, so my vote probably doesn't count for anythin
  7. Sounds nice in principle, but I'm with Zador... Christmas tree clutter, and just makes things more confusing to newcomers, who are the ones who are the ones most likely to post stuff in the wrong place. Enough moderators who pay attention (duly slapped by Igor and Thomas) make this a relative non-issue. But please keep the suggestions coming!
  8. I can relate to that... give me a wall of text and I go to sleep... or go looking for a better guide. MORE PICTURES! I need to clean up the other thread and use links instead of those weird embedded forum link things... that makes a relatively short post look download scary.
  9. @Igor I like! Make it into 'have you tried this yet - using good power, using good power, engaging brain' and 'if you haven't already read them, here are the docs' post, and basically sticky it? And how would that tutorials thingy work? Sort of another section of of the site, but for tutorials?
  10. My apologies on that last point... I fully deserved that... I keep thinking that the misleadingly named GPU is actually the GPU, instead of just the 3D accelerator. I'll stop there though, as this is getting away from the OT. I just wanted to bite that bullet publicly!
  11. You forgot to mention that fact that the GPU won't be that far off the CPU temperature anyway, since they're on the same die. It may be interesting though if you do hardware assisted encode/decode stuff, whoever is daft enough to use the pine64 for that :-/
  12. Only adding this as I did look at it and 'fixed' the problem, which was indeed simply wrong pattern match, due to how ubuntu's free formats things different of recent times. However, I do agree with tkaiser, it isn't really needed, as linux is supposed to use 'free' memory for caching... unused memory isn't wasted! I just didn't like the broken stats! in /etc/rpimonitor/template Modified swap.conf is like this. Modified memory.conf is like this. I also added more stuff to my Allwinner_A64.conf file, which may or may not be the right filename, I m
  13. pfeerick

    ROCK64

    Woohoo! Nice to know it will that easy... my chinglish android eEMMC install might die a sudden death now and be reborn with linux... after a backup, of course! I still find the android OS handy for usage as dumb TV box! This is the pinout document for the rock64 - hopefully it's all correct! The boot sequence on the RK3328 is external eMMC, SPI Nor Flash, SPI Nand Flash(not fitted to rock64), external SDMMC card, USB (FEL/OTG). So unfortunately eMMC before SD I hate to ruin my uptime of 1 day, 4:16, 2 users, load average: 0.00, 0.00, 0.00, but needs
  14. And you wonder why the user couldn't be faulted for plugging in a 12v 2A PSU into a product that has a 5v 700ma requirements :-P I smell lots of burning boards and refunds in the air! Confusion to be had all around. You'd think they'd know better now... tkaiser is not to be messed with... listen to him or all hell will break loose... :-P And it's not like you're doing it to for fun or are sadistically inclined (much!)... you're just trying to tell them how stupid a mistake they're making before they can fix it and are committed on the production run and the mere mortal users (like me) get to e
  15. BDR is an understatement. You were jumping up and down a bit there now 'Charles', but still, they shouldn't be publicly talking about this sort of stuff if they're not willing to put up the numbers and performance data. And as you said, calling it open source is just a bad joke on the community... open source is not just creating a new repo on GitHub! Sheesh! I'm glad I never bought into the whole Banana board thing now... I stuck with the Raspberry Pi for all it's faults, and then deliberately went to the Orange Pi Zero know its faults thanks to the sunxi and Armbian documentation because of
  16. Oops! I didn't spot that one either! Sorry @chwe ... better move it before Igor decides to cut our pay!!!
  17. yours is absolutely neat comparted to mine at the moment... pine64, orange pi zeros, rock64... arduinos, meters, parts boxes, heatsinks, nrf24L01 project boards, led matrixes... all strewn across two desks... plus a laptop or two and a tablet in there somewhere! :-O
  18. @Bubba I didn't say that, but I won't argue differently either! Good 'ol Dunning-Kruger... you just can't argue with it without proving the point!
  19. As per this post and the downloads section of the Armbian site, some boards have been moved to WIP (Work In Progress) or EOS (End of Support). The only specific H5s I'm aware of, the Orange Pi Zero 2+ H5 and the Orange Pi PC2 are both WIP boards (although from a second glance at the downloads page, it looks like all but the pinebook are H5 boards), so post this commit from 28 days ago, you'll need to set the EXPERT flag to YES in order to show WIP boards. This was done to reduce the number of support requests when people have self-built WIP board images or downloaded the nightlies and subsequ
  20. pfeerick

    ROCK64

    @TonyMac32 We're not that far away from mainline support already... at least the first digit is a 4 instead a 3!! The rockchip folks have stated that they are committed to open source, and are working towards mainline support, so fingers crossed it happens. Making this board the (if not the, then one of) the best best linux supported SBCs for 2017 and with a reasonable hardware set?
  21. I don't have any issue with any of the points raised in this thread so far. So, my 2 cents (or is it 5 cents?): Forum restructure - yes, "I" think is needed, as current three levels are restrictive. So break it out to development and tutorials at the least. Before we head down the tutorials on the forum approach though, we really do need to nail down if we do tutorial stuff on the forum, or on a wiki. If we stick with a forum approach, we could probably replicate the 'technical support' categories, to sort them, and then just standardise a layout... first post is always the update
  22. You know, it would be really helpful if you said more than "IT DOESN'T WORK"!! For instance - which image are you using? How did you write it? What power supply did you use? Have you tried other images with the pine64? What do you have plugged into it? You know, the little details that let other people get an idea of your setup and what could be going on. Otherwise I couldn't be blamed for saying that you need to tell the hamster in the wheel driving the turbine powering your pine64 needs to run a bit faster since I honestly believe at the moment you are running your pine64 via ham
  23. I meant to mention - have you thought of trying the reverse? You keep trying to ping your Orange Pi zero, which appears to be 192.168.1.40. What is the device at 192.168.1.1 you're trying to ping? Your router? your laptop? If it isn't, try pinging your laptops IP... if the Orange Pi Zero can't see it... then how do you expect to be able to ssh into your orange pi zero? One of the major problems here is that you only give us part of the information, and we have to guess the rest. We aren't clairvoyant... we don't know what testing and knowledge you do have. We're just ordinary guys and gals w
  24. I personally think that 4.80v at the rpi header is too low, especially if the Orange Pi Zero was unloaded when you measured the voltage. As a comparison for you, I just ran up a freshly downloaded build of Armbian 5.30 Debian Jessie onto a not great, but reliable microSD (I know tkaiser will be spitting chips when I say this... Sandisk Class 10 8GB - the red and grey type - it's what I had handy - but I usually use tested Samsung EVO cards - as quality cards is important). I used a power supply set to 5.30v, and a known good quality 1m microUSB lead. I loaded it up, checked the v
  25. 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 ho