pfeerick reacted to lanefu in [Moderation] Better Using "Report this content" (Flagging) for Mentoring New Mods
Mods should be able to apply Solved prefix to topics now.
pfeerick reacted to Igor in Help Test Upcoming Armbian v20.08 (Caple)!
I wasn't updating index file until all files are present on all mirrors. Now I pushed index update which will take up to 24-48h (not sure since we are doing 1st time) to update all mirrors. If we would update all at once, people will be receiving errors - file not found - all the time ... updating index from server one, then redirector points to another mirror - where files are not yet - error. Now files are everywhere, but index is somewhere still old.
Anyway, things are in automated motion now.
pfeerick reacted to MacBreaker in Seed our torrents
since years i seed Armbian torrents but i noticed that i'm running out of space.
My hdd was 248GB till now...
Looking for further information and saw in the first post is written 512GB.
Maybe you can add a big ">NOTE!< since Version 20.05.xx you need 512GB free space".
Also after you installed transmission by ->Software ->Softy ->Transmission you get asked to seed Armbian torrents.
Here a screen:
You have to change the number from 80GB to 512GB.
Just my thinking about this..
pfeerick reacted to Hijax in THE testing thread
Serial and power mux board is ready for ordering. However before I do so, I need to wait till SD card mux board redesign is complete at least overall idea is “approved”.
As previously written the major change is to switch from simple SDI interface towards SDIO one allowing full speed communication with card. This requires 8 pins thus not only mux board but also card adapter tuning.
Recently idea under consideration is to move SD mux board away from stacking and make it more alike USB Mass Storage device.
pfeerick reacted to Igor in THE testing thread
One test board from this topic will be installed at this location and another at my desk and elsewhere. We will try to join them.
After test boards come, some more coding has to be done. Also to have better overview over the test process. Currenlty test results looks like this: https://dl.armbian.com/_test-reports/2020-05-03_15.57.22.html Its still more or less a data collection without any proper analysis ...
pfeerick reacted to Igor in armbian-firmware-full vs armbian-firmware
armbian-firmware = minimal blobs that are needed that on-board wireless function + few popular ones = https://github.com/armbian/firmware
- full = + everything else https://kernel.googlesource.com/pub/scm/linux/kernel/git/firmware/linux-firmware.git
You can install one of those, while source package, headers and armbian-config are optional. Also armbian-firmware if your will not be running any wireless.
Kernel = image + dtb package. Those are the core.
pfeerick reacted to tkaiser in RockPro64
(placeholder for a Board Bring Up thread -- now just collecting random nonsense)
Board arrived today. Running with ayufan's Debian 9 image (using 1.8/1.4GHz settings for the big.LITTLE cores for whatever reasons instead of 2.0/1.5GHz) I checked for heat dissipation with Pine Inc's huge heatsink first. Huge heatsink combined with thin thermal pad shows really nice thermal values:
below 50°C when running cpuburn-a53 on two A53 and two A72 cores in parallel with a fan blowing above the heatsink's surface Board in upright positition still running same cpuburn-a53 task without fan after 20 minutes reports still below 85°C even if heatsink orientation is slightly wrong
Summary: passive cooling is all you need and you should really spend the additional few bucks on Pine Inc's well designed heatsink since being inexpensive and a great performer.
pfeerick reacted to chwe in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64
there you go.. (should be more or less correct, cause only @jmmc works on such features.. )
sure, a not powered board doesn't need much power... If you want mainline on it, the things you're interested in might come in one or two years (just my opinion)... To my knowledge, mainlining H6 is still a 'one-woman-show', so better hope that she doesn't looses interest in doing all the work.
pfeerick reacted to TonyMac32 in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64
Because Linux support is not mature for the H6? It's hard to release a distro for something that doesn't have proper kernel support. :-).
@Vincen, The Asus Tinker Board, and MQMaker MiQi have experimental video decoder and GPU support. I'm not as familiar with the other boards to know what they can and can't do in that department.
pfeerick got a reaction from AnythingIsFine in Rock64 - Armbian eMMC image
@AnythingIsFine Ouch! That sounds like me with the raspberry pi... when the recent 'disabled by default' behavior of the SSH... scratching my head to work out why the SSH wasn't working, and I'd firstly forgotten to make the enable file, then made a typo in the filename...
At least it's working now!
Hm. so the artful images... interesting... will have to poke around and see why it changed. Be handy to port that back to other images. If the artful images are using the kernel that supports it, it could be signifying disk activity...
pfeerick reacted to AnythingIsFine in Rock64 - Armbian eMMC image
Thank you for your time! On the other hand, I do apologize for wasting it.
I managed to boot up Armbian on my Rock64 and figured out that the issue was between the keyboard and chair, namely me.
I am running only headless boot on my SBCs and I just configure a static IP after flashing the respective image, which I later use SSH into post boot.
On ayufan's Ubuntu Xenial/Artful I just edited the '/etc/network/interfaces.d/eth0' file to achieve this, but when browsing the files after flashing the Armbian image, I noticed the "armbian_first_run.txt.template" file and decided to use this option instead... I edited it to boot 'eth0' to a static IP which I would use to SSH into it, just to test it out (nice feature by the way, very Raspbian-e)
Of course, I edited the file accordingly, but simply forgot to rename it to 'armbian_first_run.txt' so it may be found and read and as such the IP I set in it was not configured, hence I could not ping the IP I set up.
This mistake, coupled with the fact that the red LED was constantly on as opposed to flashing quickly during boot and then being turned off, lead me to *mistakenly* believe the Armbian image would not boot of my eMMC.
I think this is default behavior on Etcher on Windows/Linux.
When flashing an image using Etcher on my Fedora 27 Workstation computer there is no validation happening post flash process, or at least its very subtle as you point out...
When flashing an image using Etcher on my Windows 7 Enterprise SP1 computer, a validation step occurs post flash process, which roughly takes as much as the flash process itself.
As can be seen in the below link, the Ubuntu Artful image does cause the red LED to blink during boot up and turn off once the boot process is finished.
Artful-minimal-rock64-0.5.15-136-arm64 - Boot up LEDs
The Armbian image on the other hand, does not have the same behavior and the red LED just remains on the whole time, which is expected behavior according to this post (your response)
Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124 - Boot up LEDs
I wrongfully assumed that the red LED on the Rock64 had the same behaviour as the green one on the the Raspberry Pi 3B as described below.
I noticed the Rock64 Armbian image is still in its testing phase...
If there are certain tasks/test cases the good folks at Armbian would need extra help to test/implement, please let me know where I can sign up to help!
pfeerick reacted to Igor in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64
Development versions without active DVFS are usually clocked lower so performance wise we are not there yet. Reboot/power off troubles ... noticed.
Yes, ack-ed. I am waiting for another big chunk of free time to dive back in and try to fix this. I also hope that someone else will join and try to move it forward.
Support is enabled in configuration but it looks like implementation on this board needs few adjustments ... Thanks for trying out.
pfeerick reacted to Xalius in Pine64+ & Pine64so - uboot - no ethernet
I am investigating a weird issue I have with SOPine modules at the moment, GbE works fine on the Baseboard A with 4.15-rc6, but not on clusterboard, I also have an issue with MAC address assignment where the interface drops into monitor mode after a while...
pfeerick reacted to chwe in New forum UI!!
hmm... sounds familiar...
btw.. the like looks a bit messed up (looks quite that they wanna implement more reaction possibilities - I think we had this once before but disabled it?).
quote is also a mess.. the button shows up random somewhere on my browser.. --> maybe a 'opera only' feature?
pfeerick reacted to Igor in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64
First Pine H64/H6 mainline testing images based on @Icenowy patchset https://dl.armbian.com/pineh64/ Boot log: http://ix.io/18DU