Rock64 Review

[z4v4l]

They're way ahead of you...  

emmm, yah.
I was talking about this scenario: if one chip fails, the board keeps booting the normal way, because it has the second, rescue, chip. also this pair would be cool for the "unbreakable" FW update.
how this above partitioning, even though it is "way ahead of me", is going to help to achieve goals mentioned (increasing robustness, securing FW update)?

...  the SPI flash is partitioned in the mtd subsystem:  The entire SPI flash is represented (stubbed in) as several devices as follows (from cat /proc/mtd):

/dev/mtd0:    00008000   "system"
/dev/mtd1:    003f8000    "loader"
/dev/mtd2:    003c0000    "reserved"
/dev/mtd3:    00040000    "vendor"
/dev/mtd4:    00400000    "uboot"
/dev/mtd5:    00400000    "atf"

All of the above is subject to change.  "system" is stubbed.  "vendor" is being used now to keep mac addys persistent.  "uboot" is obvious,  and "atf"  is arm trusted firmware.

These partitions are being stubbed in now in preparation for booting from the on-board SPI flash.  Stay tuned here and on the irc for the ongoing discussions regarding how these partitions will change in the future; as well the future of booting from SPI flash.

( hint:  only one relatively large chip is needed;  although, the SPI nor flash is relatively tiny ! )

not to mention this "partitioning" is all uboot/linux specific. how about UEFI? for example. it has and uses its own FV (firmware volume) format, specifically designed for NOR flash.
somewhen, rockchip will throw out this uboot thing and switch to UEFI. and then...
I am in no way pretending, someone here would listen to me, just wanted to express my opinion, as an interested party outside. that better is to have SPI NOR flash for FW than play "let's push in linux there and see what happens", and better is to have 2 small chips than large 1.
Why by the way it is so big? has uboout bloated to 16 MB levels? Or that fancy ATF did? What were the reasons to pick such a monstrous size?