zador.blood.stained

Overlay file system is NOT what you want, it requires the original media to be readable.   I'd recommend a u-boot that handles net booting (if it exists) loaded to the on-board flash, then a network root and swap if needed.  One system would require real media and the others a network connection to it.

Just a heads up, I think the bigger issue between the revision 1.1 and 1.4 is that they removed the "U5" buck AVCC/RTC 3.3V converter, Instead in its place they put a "R9" 0 ohm resistor from the GPIO 3.3v regulator "u55". As such it makes sense that they removed the "Q11" gpio voltage enable switch, since now that switch must always be on.
In testing the voltages, the Rev 1.1 GPIO VCC is 3.37v, whereas the AVCC/RTC Vcc is 3.27v.
For Rev1.4 though, the GPIO/AVCC/RTC Vcc is actually 3.4v.
I am currently removing "R9" from rev 1.4 and installing a diode to drop some voltage. It may help to keep the device from overheating. If that doesn't help, perhaps adding a secondary 3.3v buck regulator can fix the issue.
 
Update: With the diode to drop voltage, the resulting voltage on AVCC/RTC is 2.91V.
This results in the following temp readings stable/finger tested:
19:02:53: 1200MHz  0.71  19%  11%   6%   0%   1%   0%   -2°C
19:02:58: 1008MHz  0.73  19%  11%   6%   0%   1%   0%   -4°C
19:03:03:  240MHz  0.67  19%  11%   6%   0%   1%   0%   -9°C
19:03:08:  240MHz  0.62  19%  11%   6%   0%   1%   0%  -10°C
19:03:13:  240MHz  0.57  18%  10%   5%   0%   1%   0%  -11°C
19:03:18:  240MHz  0.52  18%  10%   5%   0%   1%   0%  -17°C
19:03:24:  240MHz  0.48  17%  10%   5%   0%   1%   0%  -20°C
19:03:29:  240MHz  0.44  17%  10%   5%   0%   1%   0%  -21°C
This leads me to believe that the temperature may not be significantly if at all different between v1.1 and v1.4. It would make sense for the slight voltage difference of voltage on the AVCC pins would change the internal temperature readings. They probably don't have any sort of voltage reference internally, and that would lead to any sort of internal reading based on analog voltages to be affected by voltage changes of the AVCC power.
I will test this with a power supply on the seperated AVCC/RTC to see if it does indeed result in different internal readouts.
 
 
Alright, here's what I found:

All of these results are running the armbianmonitor right after start up and each show a "finger test" draw represents draw on the Avcc/rtc  from the power supply, and is quite stable.
 
Orangepi v1.4 test: r9 removed, AVCC&RTC=3.27 about 50mA draw during test:
Orangepi v1.4 test: r9 removed, AVCC&RTC=3.4V about 50mA draw during test:

Orangepi v1.4 test: r9 removed, AVCC&RTC=2.90V about 40-50mA draw during test
 
Results: The internal temperature sensing cannot be trusted, especially since there is no voltage reference.
Tomorrow I will try to place a 150mA 3.3V LDO regulator instead of "r9" and see if I can find a way to actually test temperature.

PS: I would add images if I could figure out how to do so outside of hosting them somewhere else.
 
Sidenote:
"R9" is glued down, so to minimize chance of lifting pads when desoldering try this:
1- apply generous amounts of flux from flux pen.
2) use solder wick to remove as much solder as possible
c Once all the solder is gone, rotate the part 90 degrees with flat end needle nose pliers while slightly pushing into the board.
 
If you managed to get enough solder off, the part should break free without lifting the pads. And if they do lift, you can always solder onto the test points on the board.

Going to www.armbian.com from here was possible before, but current menu (navbar) was changed several times after that.
 
Yes, but it's a separate service which has its own index page aka "home".

The thing is - forum.armbian.com is a separate site, not part of www.armbian.com. Logo on the forum should go to the forum index, not to www.armbian.com index. Same as dl.armbian.com logo goes to dl.armbian.com index, top left corner of docs.armbian.com links to docs.armbian.com index.
To compare: if you are using Google services - the "Google" logo in top left on docs.google.com, drive.google.com, play.google.com, mail.google.com, etc. doesn't link to www.google.com but to the respective service start/index page.

I just wanted to say that using those expressions as filters/tags is misleading.
 
I'm not sure that UX people that are not familiar with SBCs can understand what and why we are discussing some things. So, again, ideally we would need a CMS with visual design being as close as we can get to the current one + enhancements suggested in this thread.

I think that download pages and device list pages should be redesigned and we should take some popular websites as examples for the layout.
1. For download pages we could have a device picture on the left, stuff like download buttons to the right of that picture and other stuff below that (i.e. Aliexpress product page, Amazon product page).
2. For the device list pages we could have a list layout - one device in a row, picture to the left, name and short description to the right (i.e. Youtube channel videos list page in the old design).
 
To clarify - I'm not talking about copying any design features, I'm talking mostly about changing the layout to fit more important info on the page that is visible without scrolling and to improve the UX.

Maybe you have a card reader issue?
Did you write the image with Etcher? Unless Etcher writes the image without reporting any issues I'm not sure anyone will be able to help you further - you should try a different card reader and different SD cards first and write images only with Etcher.

To catch write errors that are not reported to the writing program.
 
Please don't try to tell this to manufacturers of low-end SD cards and USB thumb drives. Writing to block devices doesn't have any feedback mechanism that would ensure that data was written correctly. And while some SD cards were becoming read-only after detecting internal issues, other cards just silently failed to overwrite specific blocks.
 
I use a custom write-with-verify procedure integrated with the Armbian build system, and while when I had issues with the card reader writing was aborted with I/O error, writing to bad SD cards can only be detected by reading back and checksumming the data.

The thing is - forum.armbian.com is a separate site, not part of www.armbian.com. Logo on the forum should go to the forum index, not to www.armbian.com index. Same as dl.armbian.com logo goes to dl.armbian.com index, top left corner of docs.armbian.com links to docs.armbian.com index.
To compare: if you are using Google services - the "Google" logo in top left on docs.google.com, drive.google.com, play.google.com, mail.google.com, etc. doesn't link to www.google.com but to the respective service start/index page.

The thing is - forum.armbian.com is a separate site, not part of www.armbian.com. Logo on the forum should go to the forum index, not to www.armbian.com index. Same as dl.armbian.com logo goes to dl.armbian.com index, top left corner of docs.armbian.com links to docs.armbian.com index.
To compare: if you are using Google services - the "Google" logo in top left on docs.google.com, drive.google.com, play.google.com, mail.google.com, etc. doesn't link to www.google.com but to the respective service start/index page.

It won't solve the problem right away but it would be harder to miss such changes in a small file rather than in a 80+ lines long function in a 450 lines long file.
Regarding solving the problem - IMO we should push a bugfix update in a week, replacing at least board support packages - this will include armhwinfo fixes and will properly mark images as "stable" rather than "user-built".

As an example - as I proposed some time ago: platform specific performance tweaks go to a function in config/sources/$LINUXFAMILY.conf and are maintained there, this function is "extracted" into a separate file that is included by /etc/init.d/armhwinfo
Same with platform specific firstrun tweaks where they are required.
 
this block (IMAGE_TYPE related) can be moved to line 260 and this should fix the problem.

We already tried that and it didn't work well - people demanded fixes for unsupported build hosts even though they had to read the warning each time, so at least understanding what "no support" means wasn't trivial for them.
 
If you tried to build, for example, the default sun8i branch some time ago it would be a different story.

Because it tries to use (i.e. store and execute the next stage bootloader) DRAM that doesn't work properly?
 
You can try clicking on dram_*.c files here and find something like this, if it explains anything 
 
No, DRAM init code and its configuration has to be provided by bootloader/SPL. SPD is just an additional EEPROM on removable memory modules and it doesn't make much sense to use this for something that is soldered on the same board as the CPU/SoC.

It would be best to extract the Device Tree from any original image that runs on this device with Ethernet, eMMC and LCD backlight. While Ethernet and eMMC configuration can be easy to adapt from working images, LCD backlight may be difficult to enable without any documentation (i.e. device schematics).

The problem is the created confusion and armbian-config is here only part of the problem but not of a solution. It just looks in a directory for files that follow a specific naming scheme (${OVERLAYDIR}/${overlay_prefix}*.dtbo), presents them as list, you can tick checkboxes, then something will be written to another file, done. What happens after the mandatory reboot might be surprising and what's displayed depends solely on the contents of a directory defined as $OVERLAYDIR (and the contents are subject to package updates that happen somewhere else) and is not related to the hardware in question.
 
A suitable UI (it's called USER interface for a reason since it should focus on the user) would try to address the job from the user perspective. That would require:
displaying what's available as selectable hardware and what's already active, therefore not needing a DT overlay! (not happening now, usb0host for example is displayed as inactive while it's active in reality or not -- the most basic principle of an UI is already violated here) allow to only do something that really works (a lot of overlays would require additional parameters and without them activation is pretty much useless) checking and trying to resolve overlay conflicts Creating such an UI that really works is days of works but would add least be something useful and not add further to the confusion that's already there. IMO the only stuff where the current armbian-config implementation helps (activating stuff on pin headers like USB, Audio (analog-codec and I2S, SPDIF where appropriate) without the need to specifiy additional parameters) could be avoided in the first place by activating this stuff by default.
 

I don't agree that bringing here Raspberry Pi users would benefit the Armbian project.
First, another Debian/Ubuntu derivative means fragmentation of user base - not an improvement for Raspberry Pi project.
Second, IMO Armbian project needs more developers, experienced users/experts and maybe sponsors, and not a lot of inexperienced users who bought an SBC for no reason and now don't know what to do with it.

/etc/armbian-image-release and /etc/armbian-release are different files and have a different purpose. The former was added to track the source image version in case of upgrades, kernel switches, etc., it won't be present on many older images so it shouldn't be used for platform identification.

I just wanted to say that using those expressions as filters/tags is misleading.
 
I'm not sure that UX people that are not familiar with SBCs can understand what and why we are discussing some things. So, again, ideally we would need a CMS with visual design being as close as we can get to the current one + enhancements suggested in this thread.

If I remember correctly older images didn't have a required package installed (iputils-arping) so NM failed to renew a DHCP lease, though the initial lease was obtained correctly.
https://github.com/armbian/build/commit/b971b10f24bdf869b2d7ed52db9c14f5d3012d26

Did you let it run for more than 24 hours? And did you check the syslog for NM complaining about arping missing?

Done and I put a link to "Known issue" to this thread. 

I don't think there is anything to fix there. Observed issue is the old bug (either disp2, arch timer or a combination of both) which is disappearing and reappearing again randomly due to its nature. But I didn't test this yet and we can always update pine64-default branch later using a newer ayufan's branch once any of those branches in considered "stable".

I am running out of specifics - basic tests are done, problems fixed ... I have .debs ready up to latest sources and can rebuild repository. Images can be made during the night. I think current stable images have more (tiny) bugs than those waiting in the line .... since we have mainline H3/H5/A64 out of this picture. And it's also perfect timing 4.13.y is EOL ... and we push an update when 4.14.y comes into the decent state.
 
 

Update on HC2: Mass production will start in approx. 2 weeks. HC2 will be fully software compatible (same SoC, SATA bridge and even same schematics design except 12V power rails for a 3.5" HDD added on HC2). The hardware changes should be obvious: 12V DC-IN and much larger enclosure/heatsink to fit the size of 3.5" HDDs.