Rock64 Review
#11
(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
  Reply
#12
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]
  Reply
#13
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. Big Grin 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. Smile
  Reply
#14
(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. Big Grin 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. Smile


They're way ahead of you...   Tongue


...  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 ! )
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#15
(08-20-2017, 07:30 PM)MarkHaysHarris777 Wrote: They're way ahead of you...   Tongue
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):

/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? Big Grin What were the reasons to pick such a monstrous size? Smile
  Reply
#16
(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? Big Grin What were the reasons to pick such a monstrous size? Smile

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.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#17
We will use UEFI on top of u-boot once the SPI flash booting things are all figured out...
Come have a chat in the Pine A64 IRC channel >>
  Reply
#18
(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.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#19
(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"?  Big Grin 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. Big Grin
Anyway, if you are trying to adapt edk2 to really run as a firmware on this nice device, wish you good luck!
  Reply
#20
(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"?  Big Grin 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. Big Grin
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/a1...U-Boot.pdf
  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Selling Rock64's dugalbug 6 282 10-19-2019, 12:12 PM
Last Post: dugalbug
Exclamation Rock64 v2 freeze help! JuanDTM 5 203 10-16-2019, 06:37 PM
Last Post: Rocklobster
  Rock64 for video surveillance martinschm 6 421 09-19-2019, 01:56 AM
Last Post: Jozek
  ROCK64 not booting TheGiolly 10 434 09-09-2019, 06:57 AM
Last Post: Rocklobster
  Rock64 v3 - POE P1V 3 545 08-18-2019, 05:51 AM
Last Post: mcerveny
  Rock64 board seems defective, how to confirm? Josk 1 166 08-15-2019, 08:24 PM
Last Post: tllim
  Purchase Rock64 V3? richardk 6 668 08-03-2019, 12:56 PM
Last Post: mcerveny
  Rock64 running OMV, how to setup RTL8812AU WiFi? electrosam 2 201 07-16-2019, 04:03 PM
Last Post: ayufan
  Rock64 random freezes BTB 3 304 07-01-2019, 10:17 AM
Last Post: Luke
Sad Rock64 Seafile Installation klaus_nase 2 223 06-27-2019, 09:11 AM
Last Post: klaus_nase

Forum Jump:


Users browsing this thread: 1 Guest(s)