+- PINE64 (https://forum.pine64.org)
+-- Forum: ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=85)
+--- Forum: General Discussion on ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=86)
+--- Thread: Rock64 Review (/showthread.php?tid=4958)
RE: Rock64 Review - stuartiannaylor - 08-19-2017
(08-19-2017, 08:29 PM)MarkHaysHarris777 Wrote:(08-19-2017, 08:08 PM)MarkHaysHarris777 Wrote:(08-19-2017, 07:44 PM)stuartiannaylor Wrote: The enclose the Pi in plastic and make it impossible to fit things like the CSI camera ribbon and others.
Highly functional as in glossy plastic?
Your false statement is the one above; not an opinion, clearly a false statement.
I mean, you don't even attempt to qualify the statement, you simply state that it's impossible !
Thank you mark your opinion is much appreciated
RE: Rock64 Review - Vyssute - 08-20-2017
Recieved the Rock64 2Gb with64Gb SDcard. Install of Android 7.1.2 was a piece of cake. Initial startup Video attached.[video=facebook]https://m.facebook.com/story.php?story_fbid=10209476734104454&id=1508955968[/video]
RE: Rock64 Review - z4v4l - 08-20-2017
As a person interested in firmware development, it's so nice to see that Rock64 features SPI NOR flash. But I have a suggestion in this respect. 16MB is huge, even more than needed.
This way you only encourage fw writers to do bloatware.) seriously, I think it would be even cooler to put 2 smaller SPI NOR flash chips, say not bigger than 2MB each. instead of this huge one. For reliability. x86 motherboards often do this way. It's a practice. Also eMMC has 2 boot "partitions" for the same reason in the standard. It would be more reliable to have 2 discrete firmware devices than to have 2 copies of the fw on the same bigger device. Is it possible with rk3328? I think yes. maybe for later revisions of the board? Installing there an OS is a bad idea, better is using network boot if local storage is not an option. NOR is for firmware and having 2MB is way enough. but for the longevity, better to have 2 such chips on board. just a thought. 
RE: Rock64 Review - MarkHaysHarris777 - 08-20-2017
(08-20-2017, 06:42 PM)z4v4l Wrote: As a person interested in firmware development, it's so nice to see that Rock64 features SPI NOR flash. But I have a suggestion in this respect. 16MB is huge, even more than needed.
They're way ahead of you...
... 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 ! )
RE: Rock64 Review - z4v4l - 08-21-2017
(08-20-2017, 07:30 PM)MarkHaysHarris777 Wrote: 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)?
Quote:... 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):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.
/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 ! )
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?
RE: Rock64 Review - MarkHaysHarris777 - 08-21-2017
(08-21-2017, 07:49 PM)z4v4l Wrote: Why by the way it is so big? has uboout bloated to 16 MB levels? Or that fancy ATF did?
The reason is that the entire board can from from SPI nor flash; gnu+linux.
... we are experimenting with running small linux foot-print entirely on the SPI flash !
Your scenario above is not likely ( that the SPI flash chip will give out needing a secondary backup ! ) This very unlikely rare scenario does not warrant a redesign of the board, IMHO.
For all intents and purposes multi formatting in the mtd subsystem is a very workable solution; great flexibility, and robust reliability too.
Note: there is no eufi, nor will there be.
RE: Rock64 Review - xalius - 08-22-2017
We will use UEFI on top of u-boot once the SPI flash booting things are all figured out...
RE: Rock64 Review - MarkHaysHarris777 - 08-22-2017
(08-22-2017, 09:21 AM)xalius Wrote: We will use UEFI on top of u-boot once the SPI flash booting things are all figured out...
Noted, and corrected. thanks.
RE: Rock64 Review - z4v4l - 08-22-2017
(08-22-2017, 09:21 AM)xalius Wrote: We will use UEFI on top of u-boot once the SPI flash booting things are all figured out...
holy guacamole. you mean you will use the linux feature to interact with a bootloader as an UEFI app and uboot feaure to pretend being UEFI, or you really will be running the second firmware after another one? why? is it because Tianocore has not been ported enough or is it a "design decision"?
In the latter case it's like carry a cow on your back while running a bicycle.) Better to let the cow run the bicycle by itself. Anyway, if you are trying to adapt edk2 to really run as a firmware on this nice device, wish you good luck!
RE: Rock64 Review - stuartiannaylor - 08-22-2017
(08-22-2017, 04:28 PM)z4v4l Wrote:(08-22-2017, 09:21 AM)xalius Wrote: We will use UEFI on top of u-boot once the SPI flash booting things are all figured out...
holy guacamole. you mean you will use the linux feature to interact with a bootloader as an UEFI app and uboot feaure to pretend being UEFI, or you really will be running the second firmware after another one? why? is it because Tianocore has not been ported enough or is it a "design decision"?
Anyway, if you are trying to adapt edk2 to really run as a firmware on this nice device, wish you good luck!
Its BL3 though isn't it where it could be either u-boot or UEFI?
Arm are not supporting UEFI in exactly the same way but its the arm-trusted-firmware where at BL3 it can branch out to either UEFI or U-Boot.
That is sort of how I read things.
https://wiki.linaro.org/ARM/UEFI
https://www.suse.com/docrep/documents/a1f0ledpbe/UEFI%20on%20Top%20of%20U-Boot.pdf