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
#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]
#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
ANT - my hobby OS for x86 and ARM.
#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! )
#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
ANT - my hobby OS for x86 and ARM.
#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! )
#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 IRC channel >>
#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! )
#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!
ANT - my hobby OS for x86 and ARM.
#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


Possibly Related Threads…
Thread Author Replies Views Last Post
  Rock64 No Audio @ Debian 12 dmitrymyadzelets 1 113 03-18-2024, 06:56 AM
Last Post: diederik
  Rock64 bricked shawwwn 7 5,448 03-17-2024, 12:22 PM
Last Post: dmitrymyadzelets
  Rock64 won't boot luminosity7 10 3,863 03-16-2024, 08:33 AM
Last Post: dmitrymyadzelets
  Rock64 doesn't boot dstallmo 1 254 03-16-2024, 08:29 AM
Last Post: dmitrymyadzelets
  How well does Rock64 deal with HDR and Atmos on Kodi? drvlikhell 3 1,770 04-29-2023, 04:24 AM
Last Post: newestssd
  OpenWRT on the Rock64 CanadianBacon 12 7,790 04-24-2023, 12:40 PM
Last Post: arunkhan
  Rock64 board not working, no HDMI no Ethernet. EDited 3 3,396 01-17-2023, 02:31 PM
Last Post: Flagtrax
  ROCK64 v3 can it boot from USB? Tsagualsa 4 1,973 11-29-2022, 11:31 AM
Last Post: Macgyver
  rock64 v3 spiflash Macgyver 0 703 11-28-2022, 02:18 PM
Last Post: Macgyver
  my rock64 dosen't work rookie_267 0 905 10-07-2022, 07:50 PM
Last Post: rookie_267

Forum Jump:


Users browsing this thread: 1 Guest(s)