valant

@valantissue is more complicated than just some config option. Currently U-Boot doesn't support voltage regulators and rely on ATF to enable them (A64 has HDMI voltage supply pin). Logic in ATF will turn on all referenced voltage regulators, which is mostly fine. Issue is in word "mostly" - this logic will prevent ethernet PHY to power on correctly on OrangePi 3. Distros must decide what is lesser evil for time being, having no HDMI and ethernet in U-Boot or having no ethernet in Linux on OrangePi 3 (I didn't check what Armbian does exactly). Situation was discussed with maintainers and consensus is to implement voltage regulator driver in U-Boot, but that will take time. In the mean time, ATF could be updated with a improvement, which would temporary solve both situations, but I didn't find any patch for that yet.

well, I added writing into the second gigabyte in my loader and it showed this result:
first, the code has been writing into every 8-byte word, starting at the 2nd gigabyte. and it failed at the 37th 8-byte word inside of the 129th page or passing ~512KB. I ran it twice and it failed at the same position. The fail is "synchronous abort" exception. second, the code has been changed to write first 8-byte word on every 4KB page starting from the 2nd gigabyte up to the last page (bffff000). I run this code twice and it passed it successfully both times. After the loop, the code read back the starting word and it matched. So, I suppose, it's not that bad as a bad soldered bank. instead, there are some bad pages, maybe even just 1. Too bad uboot doesn't do any testing or at least doesn't report bad pages as for example UEFI does, passing this for an OS. Basically because of some broken bits, maybe not more than occupying just one page,  entire gigabyte is cut off... that sucks. 
Well, thanks @Igor and @martinayotte for your advices.

Perhaps an image from the download section doesn't have this problem ... you are using some very old build. I only have two Pinebooks and on both 2Gb memory is properly detected.
 
Fixing this stock garbage (kernel 3.10.y / legacy u-boot) is pointless, while 2G should work OOB with a modern kernel.
 
Try.

Thank you! Oh my god, I feel so stupid - the post about exactly this is just on this very page!

Split cold non-booting issue to own topic, still need to review HDMI topic. 
 
In other news, I noticed my 4.14.80 install mentioned I had an SDR104 SDHC and that it had successfully tuned the phase, not something I remember seeing before (haven't looked in a long time)
 
So with the typical iozone parameters I got  > 66 MB/s random read, and  > 58 MB/s random write.  Not too shabby.     (SD Card:  SanDisk Extreme 32 GB U3)
File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 3228 3295 12302 12802 11459 5036 102400 16 10544 10785 30695 30729 30434 15796 102400 512 51482 50931 62070 61959 61823 48392 102400 1024 58030 58118 63218 63221 63333 53391 102400 16384 57062 60069 68049 67967 68066 59411  

SDR104 is enabled for the SDMMC interface, and if you look at the iozone testing I did above I was getting well over 50 MB/s, exceeding the SDR50, maximum.

Another note:

I have disabled video in U-boot on this architecture for now, there have been changes to the HDMI drivers within the Rockchip family that the old patches may not be properly addressing, specifically the RK3288 has been split from the rest of the Rockchip code.

Sent from my Pixel using Tapatalk

Using performance gov on opi PC with Sandisk 16GB A1 on a usb card reader

 
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 3546 3573 5092 5086 4412 2948 102400 16 4588 8634 15272 15273 13885 7955 102400 512 21594 30277 36395 36542 35605 27344 102400 1024 28300 32080 36932 37035 36661 26242 102400 16384 30036 32860 37809 37933 37894 28773 iozone test complete. Purchased from aliexpress ($5) but the scratch & verify sticker says it's genuine
 
My samsung evo 64gb went read-only recently (20 months old) and then would not boot. I copied to another card and ran fsck and all seems OK. I think the later evos were not as well made as the earlier batches.
 
 

Renegade has the wiring on board for UHS-I. SDR104 works great for me. rock64 doesn't support UHS-I from what I read. Not sure about rock64pro.

As expected. Personally not experienced with any RK3328 device (since never attached displays to them) but with older Allwinner SoCs I measured a ~5°C difference with HDMI active or not.
 
It's just as adding a GPU to a PC: Wastes more energy and generates more heat. With SoCs it's more IP blocks active and HDMI PHY inside the SoC so more or less as expected (or an indication for a driver doing things correctly: detecting a display and if none present disabling stuff that's not needed)

If 'armbianmonitor -v' reports corrupted packages then something went already horribly wrong and usually there's no easy way to recover from this other than starting from scratch. Seriously: if you have corrupted packages what should be the result if any other software calls such a corrupted library? It will just cause more and more harm.

Ah, ok. You were really running the 'armbianmonitor -c' check testing for data integrity (I thought about a fsck first). Yeah, then the SD card is at fault and corrupting data.

Instead of following stupid networkmanager bashing you might better focus on reality. What you obviously experience is filesystem corruption and quite normal with SBC (result of broken/counterfeit SD cards). In such a situation a filesystem check would be a good idea as well as some integrity checking (of packages and the entire SD card surface):
sudo armbianmonitor -v armbianmonitor -c $HOME

What if you do :
mv /var/lib/apt/lists/apt.armbian.com_dists_xenial_InRelease{,.bak} apt update ?
 
 
If that fails miserably, just do :
mv /var/lib/apt/lists/apt.armbian.com_dists_xenial_InRelease{.bak,}  

I don't know actual implementation details, but defining "bootargs" variable with "booti" command works, since I'm using that during development... I think I heard that bootm doesn't work with aarch64 kernels and I didn't even try it.

Same as with other Cortex-A53 AW SoCs, it starts in aarch32 mode. I doubt they changed BROM functionality much.
 
If you are using mainline U-Boot, that shouldn't bother you, since SPL switches to aarch64.

Its finally out.

At $60 that's a definite want.  At $110 you need to show me why I need all those connectors.  

You might better try to educate yourself about what really happened. Bananas and Oranges are Cubieboard descendants which itself is in a line with Mele A1000 (or more in general: Allwinner A10/A20 based Android devices that were popular in China and were exported later by Tom Cubie which kickstarted more or less linux-sunxi community, Cubietech and sites like CNX). These origins on A10/A20 happened in 2012 when RPi software support was still very limited. Below one rackmounted Mele A2000 cluster (real Ethernet and real SATA combined with SSDs made the difference to toys):
 


 
Even the power plug used on Bananas and Oranges is inherited from those first Mele TV boxes!
 
At the time RPi was in early development Beagleboard was already there, ODROIDs were already there and in China they had something similar to RPi already years before (QQ2440 and Mini2440 are FriendlyARM products, yes the company now selling NanoPis since Westerners are that stupid that they only can accept a good SBC design if it has Pi in its name)
 
When speaking about RPi it's more or less about Western perception and of course marketing (that's where the RPi Foundation really excels)

Even in a perfect condition those forum functions are sadly not working perfectly fine. For reporting and discussing bugs, this place should be a good start: https://invisioncommunity.com/forums/forum/497-peer-to-peer-technical-support/

I am always in doubt when a new forum update is out since we don't have resources to fix bugs inside forum engine "Will this new one actually fix some of the bugs or introduce new ones?" "Do I have the time to apply quick fixes in case of major problems?" ...

Congratulations!
 
That said, the laws of physics still hold, and you missed providing the relevant information concerning your supply of choice:  The voltage of the supply.  Also, see:
 
That post contains empirical data and observations while running the Tinker Board.   If you wish to continue this discussion, we can do it in the review thread as it is off-topic for this thread.  I would actually recommend that @chwe or another moderator make that move of these last two (or more as deemed prudent) posts to that thread if possible, since we're far off topic of RK3328 vs RK3288 and the power discussion may be enlightening to others. 
 
From that post:
 
Remember that Armbian gives users the flexibility to run off of USB (after booting SD of course), and that use case would be a complete failure without spending some time seeing warnings like those above.  I also am referencing "as packaged" when I discuss the "factory" heat sink, since obviously with fans/etc it will perform better.  I can operate at a continuous 1.5 GHz with 30 second or so "sprints" at 1.6 when it cools slightly at full load, simply by attaching a superior low-cost heat sink, something I would highly recommend to anyone who did not want to suffer immediate and severe throttling (45 to 55% throttling is severe).  Add a fan and it may never throttle under normal use.

Any word on something like orange pi pc3 (lan and usb3)

esspressobin is affected by insanely high delivery cost instead.

esspressobin is affected by insanely high delivery cost instead.

@valant
 
Yeah, I mean that, but if I understand you correctly, you need just a basic (static?) setup, without any bells and whistels. Then you should probably check U-Boot implementation located here. It is much more basic and it can be reduced even further if you remove audio related stuff. If you want to support only one predefined resolution, then you could also remove all DDC/EDID related stuff. Both changes will probably leave you with only half of the code. I think this is really bare minimum for DW HDMI.
 
i.MX6 documentation should suffice for such setup. You can even find original pre-release version of DW HDMI documentation on some Chinese forum (I don't know which), but as I said, i.MX6 doc is enough for probably everything you need.

@valant
I can give you some help since I'm working on Allwinner DW-HDMI implementation, but what you asking is totally platform dependant. At least on Allwinner, LCD controller (called TCON) is just something which outputs raw data on parallel or LVDS interface. If you want anything else (TV, HDMI, MIPI-DSI) you must chose pipeline which has encoder right behind LCD controller. So it looks something like:
 
LCD:
Display Engine (HW composer) -> TCON (LCD controller) -> LCD panel
 
HDMI:
Display Engine -> TCON -> HDMI
 
I took a quick look at your BSP code and it seems that you have same situation. That means that LCD controller needs to be enabled and properly set up in order to use HDMI.
 
If you are writing driver for mainline kernel or U-Boot, you are fortunate that most heavy lifting is already done for DW HDMI. You just use library provided inside. If your SoC uses Synopsys PHY, you just need to provide few numbers extracted from BSP driver and some boilerplate code. Unfortunatelly, you have to write full DRM driver for, I'm not sure how there is called, Display Engine and/or (only?) LCD controller.