mpmc
-
Posts
18 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by mpmc
-
-
Not sure what I'm looking for, I've not even noticed any difference. I'm sure there is, but I can't see it. And this is a good thing!I originally did it on my Orange Pi Zero & didn't notice ANYTHING different so did it on my PC and couldn't notice it there either!Update: OK I've found the change to zram on the PC but not the Zero, even after an update!
Orange Pi Zero -> http://ix.io/1dIO [Updated] http://ix.io/1dJ3
Orange Pi PC -> http://ix.io/1dIA
/me has no idea what to look for.I hope this helps though!
-
Thanks for the heads up, I shall keep using "next" then & watch this thread
-
Are you able to paste what command/script you're using? I'll happily give it a run on my TB.
-
5 hours ago, TonyMac32 said:
Well, that's exactly the reason. ;-). The video codec/etc are not yet implemented in mainline.
I've just installed your debs on stretch, ran into a minor hiccup, but otherwise it seems to run fine - log http://ix.io/F88
SpoilerSelecting previously unselected package linux-u-boot-tinkerboard-default.
dpkg: regarding .../linux-u-boot-tinkerboard_5.40_armhf.deb containing linux-u-boot-tinkerboard-default:
linux-u-boot-tinkerboard-next conflicts with armbian-u-boot
linux-u-boot-tinkerboard-default provides armbian-u-boot and is to be installed.dpkg: error processing archive ./linux-u-boot-tinkerboard_5.40_armhf.deb (--install):
conflicting packages - not installing linux-u-boot-tinkerboard-default
Setting up linux-dtb-rockchip (5.40) ...
Setting up linux-headers-rockchip (5.40) ...
Compiling headers - please wait ...
Setting up linux-image-rockchip (5.40) ...
update-initramfs: Generating /boot/initrd.img-4.4.112-rockchip
update-initramfs: Converting to u-boot format
Errors were encountered while processing:
./linux-u-boot-tinkerboard_5.40_armhf.debfix: remove linux-u-boot-tinkerboard-next & install linux-u-boot-tinkerboard
HTH
-
Just thought I'd chime in here and say mine has been running fine headless on next/mainline
- log http://ix.io/F6V.
But why anyone would want to use (channeling my inner tkaiser here) crusty 4.4 is beyond me, well.. unless the feature is missing from mainline.
I'm more than happy to try 4.4 though if it would help!
-
54 minutes ago, chwe said:
Yet another H3 board...
IMO there's 'not much' where this board shines for 'another H3 board'.
Exactly, I saw the board(s) and thought, why?! What does this do better than any Orange Pi H*?
-
3 minutes ago, ullbeking said:
@mpmc Is this with OPi Zero rev. 1.4?
And are you saying that recent kernel versions include changes so that it doesn't run so hot? So that the effects of this hardware change can be mitigated by this software change?
I looked at my boards (I ordered a few) and they all have the rev. 1.4 changes pictured near the start of the thread. Unless I can get them to idle cooler, and also perform cooler under load, they will be practically useless.
I believe it's the older version.
-
Just thought I'd pop in and report that on my zero running the nightly stretch, the temp seems to have gone down a hell of a lot (when idle).
It used to get quite toasty (58c+) idle but now it's much better & this is with the xradio enabled (I had it off before)!
Well done guys!
Spoilermark@192.168.1.100's password:
___ ____ _ _____
/ _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) |__ /___ _ __ ___
| | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | / // _ \ '__/ _ \
| |_| | | | (_| | | | | (_| | __/ | __/| | / /| __/ | | (_) |
\___/|_| \__,_|_| |_|\__, |\___| |_| |_| /____\___|_| \___/
|___/Welcome to ARMBIAN 5.34.171113 nightly Debian GNU/Linux 9 (stretch) 4.13.12-sunxi
System load: 0.00 0.00 0.00 Up time: 10:01 hours
Memory usage: 9 % of 493MB IP: 192.168.1.100
CPU temp: 44°C
Usage of /: 8% of 15G
-
8 hours ago, Igor said:
Perhaps I should emphasize "approximately" more? Or remove this date since it only creates an extra pressure? Or is it ok?
It already has an obvious answer. Remove it and release when good and ready! I'm sure people would rather have a well tested and stable release!
Keep up the good work!
-
Just thought I'd pop in to say my tinkerboard has been powering a C.H.I.P and an FM transmitter (500a) for 20 days+ now without much issue. I'm just about to reflash it with Debian :).
SpoilerWelcome to ARMBIAN 5.32 user-built Ubuntu 16.04.3 LTS 4.11.6-rockchip
System load: 0.00 0.00 0.00 Up time: 20 days
Memory usage: 2 % of 2007MB IP: 192.168.1.104
CPU temp: 33°C
Usage of /: 4% of 29GLast login: Thu Oct 5 13:27:15 2017 from 192.168.1.103
-
-
Update:
I'm happy to report that my tinkerboard and northpada power supply - are still alive and in one piece (including the cables/connectors, yes I checked) - after being continually under load for almost three days. The board (under a GPIO connected fan) and psu got warm, but not hot to touch at any point, the microusb connection on the board, never once got warm.
BUT:
@tkaiser is right - even if the manner he goes about it is less than tactful - the board should be powered by GPIO. But in my case, headless usage with only a few devices connected, I don't foresee any issues. So if you plan on powering by the microusb connector (which isn't recommended
) it should be okay with a decent PSU, well in my case it is, but YMMV.
-
1 hour ago, tkaiser said:
It uses /etc/armbianmonitor/datasources/soctemp which is a symlink created at boot trying to use the correct temperature source (there's some confusion and changes wrt RK3288 kernels going on -- you might follow this and check available thermal zones yourself)
Thanks, I've checked all listed..
25 minutes ago, tkaiser said:That's the reason why anyone permanently dealing with this shit show called 'powered by Micro USB' gets annoyed sooner or later.
You can attach whatever you want with an amperage rating as high as some thousand amps to a Micro USB port and it won't help since it's not about amperage but about voltage drops.
Again, you're telling me something I already know!
QuoteIn my opinion boards with a boot peak consumption above 800mA that use this shitty Micro USB connector by default should be phased out.
I agree.
QuoteYou either had luck so far or by chosing a PSU that is advertised to power shitty devices by design you chose one that is prepared to compensate for the Micro USB voltage drops (then it's a 5.25V PSU and not a 5V PSU).
No luck, I just didn't go for the cheapest adapter available!
QuoteBut even if your PSU is prepared for those voltage drops the situation with Tinkerboard is still just a shit show since Micro USB is not specified for anything higher than 1.8A -- just grab a magnifying glass and look at those laughable tiny contacts. If you like pictures like that below just give it a try to overload these tiny contacts with a 3A load. Please take a video and upload it somewhere so we can all have a laugh.
you are a real lovely person. Schadenfreude isn't a nice trait to have, but whatever floats your boat.
-
I'm already aware of the limits of microUSB
Adding "Is this clear?" really wasn't needed, makes you sound stressed . And, yes I've already read those posts .
This board without anything attached consumes (at peaks) more power that it's possible to deliver via microUSB connector.
Well, this NorthPada adapter must be certainly able to handle it as It hasn't once crashed for the past few weeks, I've left it alone for 5 days (without a reboot) & went to check it was still up, uptime said 5 + days, so no reboot had occurred. I crashed it myself using stress trying use more RAM than allowed (just to see if I could)
.
---
Please bare in mind I'm only testing whether this adapter is able to keep the board alive with some devices & so far it has, I'm not expecting it to be able to power a dozen devices and the board without some issues, that would be stupid.
-
9 hours ago, Choryu Park said:
... snip ..
What power supply are you using, brand?
I'm currently testing this NorthPada adapter & it seems to be coping extremely well (so far).
using
openssl speed -multi $(grep -ci processor /proc/cpuinfo)
to give it a good workout
Here's what armbianmonitor says:-
Spoiler07:42:25: 1800MHz 8.11 76% 13% 62% 0% 0% 0% 68.1°C 07:42:31: 1800MHz 8.10 76% 13% 62% 0% 0% 0% 68.5°C 07:42:36: 1800MHz 8.10 76% 13% 62% 0% 0% 0% 69.2°C 07:42:41: 1704MHz 8.09 76% 13% 62% 0% 0% 0% 68.8°C 07:42:46: 1704MHz 8.08 76% 13% 62% 0% 0% 0% 63.8°C 07:42:52: 1704MHz 8.07 76% 13% 62% 0% 0% 0% 63.3°C 07:42:57: 1704MHz 8.07 76% 13% 62% 0% 0% 0% 63.8°C 07:43:02: 1704MHz 8.06 76% 13% 62% 0% 0% 0% 62.1°C 07:43:07: 1704MHz 8.06 76% 13% 62% 0% 0% 0% 61.2°C 07:43:13: 1704MHz 8.05 76% 13% 63% 0% 0% 0% 62.1°C 07:43:18: 1704MHz 8.05 76% 13% 63% 0% 0% 0% 61.7°C 07:43:23: 1704MHz 8.04 77% 13% 63% 0% 0% 0% 60.8°C Time CPU load %cpu %sys %usr %nice %io %irq CPU 07:43:29: 1704MHz 8.04 77% 13% 63% 0% 0% 0% 60.0°C 07:43:34: 1704MHz 8.04 77% 13% 63% 0% 0% 0% 61.2°C 07:43:39: 1704MHz 8.03 77% 13% 63% 0% 0% 0% 61.7°C 07:43:44: 1704MHz 8.03 77% 13% 63% 0% 0% 0% 60.0°C 07:43:50: 1704MHz 8.03 77% 13% 63% 0% 0% 0% 59.5°C 07:43:55: 1704MHz 8.02 77% 13% 63% 0% 0% 0% 59.5°C 07:44:00: 1704MHz 8.09 77% 13% 63% 0% 0% 0% 60.8°C 07:44:06: 1704MHz 8.09 77% 13% 64% 0% 0% 0% 59.5°C 07:44:11: 1704MHz 8.08 77% 13% 64% 0% 0% 0% 59.1°C 07:44:16: 1704MHz 8.07 77% 13% 64% 0% 0% 0% 59.5°C 07:44:22: 1704MHz 8.07 77% 13% 64% 0% 0% 0% 59.1°C 07:44:27: 1704MHz 8.06 77% 12% 64% 0% 0% 0% 58.2°C 07:44:32: 1704MHz 8.06 77% 12% 64% 0% 0% 0% 58.2°C 07:44:37: 1704MHz 8.05 77% 12% 64% 0% 0% 0% 58.6°C 07:44:43: 1704MHz 8.05 77% 12% 64% 0% 0% 0% 57.7°C Time CPU load %cpu %sys %usr %nice %io %irq CPU 07:44:48: 1704MHz 8.04 77% 12% 64% 0% 0% 0% 58.6°C 07:44:53: 1704MHz 8.04 78% 12% 64% 0% 0% 0% 60.4°C 07:44:59: 1704MHz 8.04 78% 12% 64% 0% 0% 0% 60.4°C 07:45:04: 1704MHz 8.03 78% 12% 65% 0% 0% 0% 59.1°C 07:48:46: 1704MHz 8.15 80% 11% 68% 0% 0% 0% 59.1°C 07:48:51: 1704MHz 8.14 80% 11% 68% 0% 0% 0% 58.2°C 07:48:57: 1704MHz 8.13 80% 11% 68% 0% 0% 0% 58.2°C 07:49:02: 1704MHz 8.12 80% 11% 68% 0% 0% 0% 58.2°C 07:49:07: 1704MHz 8.11 80% 11% 68% 0% 0% 0% 60.0°C 07:49:13: 1704MHz 8.10 80% 11% 68% 0% 0% 0% 59.5°C 07:49:18: 1704MHz 8.09 80% 11% 68% 0% 0% 0% 60.4°C 07:49:23: 1704MHz 8.08 80% 11% 68% 0% 0% 0% 60.4°C 07:49:28: 1704MHz 8.08 80% 11% 68% 0% 0% 0% 60.0°C 07:49:34: 1704MHz 8.07 80% 11% 68% 0% 0% 0% 61.2°C 07:49:39: 1704MHz 8.06 80% 11% 69% 0% 0% 0% 61.7°C 07:49:44: 1704MHz 8.06 80% 11% 69% 0% 0% 0% 60.8°C 07:49:50: 1704MHz 8.05 80% 11% 69% 0% 0% 0% 61.7°C 07:49:55: 1704MHz 8.05 80% 11% 69% 0% 0% 0% 61.2°C 07:50:00: 1704MHz 8.12 80% 11% 69% 0% 0% 0% 61.2°C Time CPU load %cpu %sys %usr %nice %io %irq CPU 07:50:06: 1704MHz 8.11 80% 11% 69% 0% 0% 0% 61.7°C 07:50:11: 1704MHz 8.10 80% 11% 69% 0% 0% 0% 61.7°C 07:50:16: 1704MHz 8.09 80% 11% 69% 0% 0% 0% 60.8°C 07:50:22: 1704MHz 8.08 80% 11% 69% 0% 0% 0% 61.2°C 07:50:27: 1704MHz 8.08 81% 11% 69% 0% 0% 0% 61.7°C 07:50:32: 1704MHz 8.07 81% 11% 69% 0% 0% 0% 62.9°C 07:50:37: 1704MHz 8.06 81% 11% 69% 0% 0% 0% 62.5°C 07:50:43: 1704MHz 8.06 81% 11% 69% 0% 0% 0% 62.1°C 07:50:48: 600MHz 7.41 81% 10% 69% 0% 0% 0% 48.2°C 07:50:53: 600MHz 6.82 80% 10% 69% 0% 0% 0% 46.8°C 07:50:58: 600MHz 6.27 80% 10% 69% 0% 0% 0% 45.0°C 07:51:03: 600MHz 5.77 80% 10% 69% 0% 0% 0% 42.3°C 07:51:08: 600MHz 5.31 80% 10% 69% 0% 0% 0% 41.8°C 07:51:13: 600MHz 4.88 80% 10% 69% 0% 0% 0% 41.4°C 07:51:18: 600MHz 4.49 80% 10% 68% 0% 0% 0% 40.5°C
This is with the following attached:
FM transmitter - not sure what that's drawing but I remember (when buying it) the seller said 500mv, but I dunno.
A next thing co, c.h.i.p - Have no idea what that draws.
I did attach a 5200mah battery in charge mode along with the above which was happily charging away until I killed the board running stress in a stupid manner, it would not boot again with the battery attached, so I suspect the battery screamed "I want more" & was duelling it out with the others, when the power was returned to the board, En GARDE!
---
The armbianmonitor output looks wrong (to me), surely it should've gotten much hotter? The drop down to 600MHz was when openssl finished. I can't be sure whether the drop to 1704MHz was also because openssl had finished or it throttled?
I've also purchased a usb doctor thing to measure the draw so should be able to give the result of that too when it arrives.
-
1 hour ago, marcopete87 said:
Does anyone have any idea about this issue?
Hi there,
This sounds like a power supply issue/It's drawing too much power, I use a 5V3A on my Tinkerboard to avoid this. I haven't tested whether or not the PSU is able to provide the advertised 3A yet, I'm in the process of testing that out today, I'll edit/come back & let you know of my results.
The "Before reporting problems with your board running Armbian, check the following:" above has some helpful info too.
-
Thanks for your hard work getting the Tinkerboard running Armbian guys!
On 17/07/2017 at 1:57 PM, lafalken said:Sounds great! Would like to see an clean version without desktop too.
I would like to use this card as webb server, but is it stable enough for such use? For that I would use a usb-hdd, network cable and power. All other things like wireless is of no use for me. But a reboot that does not work is not very good ;(
I'd like to use it headless as well running Debian instead of Ubuntu, transcoding would be a bonus, but not required!
I'm currently not using the board, waiting for things to stabilise a bit more.. I've set it up (with a 3amp PSU) & it's ready to go. I'm more than happy to test some images on it though if needed.
RK3328 Kernel
in Tinkerboard
Posted
The following issue may have already been reported, so apologies if it has.
Fresh install of both desktop 18.04 and Stretch next (Armbian_5.59_Tinkerboard_Debian_stretch_next_4.14.67) on the Tinkerboard Ethernet comes up but does not connect without manual intervention., on the desktop I had to login and connect manually, with the "server" edition I had to modify the interfaces file to get an address.
Intentional or a bug?