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
  rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? hunderteins 8 1,440 Yesterday, 12:29 PM
Last Post: simonsouth
Thumbs Up General firmware section for the Rock64? BowerR64 3 224 09-25-2020, 07:40 AM
Last Post: theophile
  Rock64 No Audio - Solved wbecks 10 9,653 09-05-2020, 02:32 PM
Last Post: WarpLover
  what is the rock64 good for? munocat 4 1,130 09-02-2020, 08:40 PM
Last Post: BowerR64
  pin connector on rock64 jeanmichel 0 140 08-22-2020, 10:04 AM
Last Post: jeanmichel
  Rock64 random freezes BTB 6 1,492 08-19-2020, 05:59 AM
Last Post: wilsonYan
  Rock64 Real Time Clock nohandlebars 1 340 07-03-2020, 06:47 AM
Last Post: t4_4t
  Got an error message when trying to flash the Rock64 OS ilan 0 320 06-29-2020, 04:53 PM
Last Post: ilan
Big Grin Rock64 as a retro-gaming console: early impressions Luke 53 34,813 06-25-2020, 09:22 AM
Last Post: dagijay
  HDMI noise on Rock64 ab1jx 1 453 06-19-2020, 04:54 PM
Last Post: ab1jx

Forum Jump:


Users browsing this thread: 1 Guest(s)