Jump to content

ROCK64

Xalius

By Xalius
in Rockchip

 Share

Recommended Posts

TonyMac32

TonyMac32

Posted
Posted
4 hours ago, zador.blood.stained said:

I believe SPI NOR kernel drivers should be smart enough to handle chip specific quirks. Also it's possible to activate SPIdev instead of MTD NOR and poke the flash with "flashrom"

 

This wouldn't be a chip-specific quirk, this would be back at the SPI driver itself, and would cause problems with any device attached to a given transmission line.  I didn't give a clean enough break between the topics, the SPI mode used, I agree, the driver should handle, but I always like to double check.  As for a needed sample delay due to routing capacitance, there is no automatic software solution that can talk to that, essentially the data received is just wrong/arbitrary, it would be a physical layer issue with the trace lengths/long parallel runs/coupling to other traces/etc.

 

@Xalius, can you grab a shot of a single transaction (16 bits?) and grab the rise/fall time of the Clock, MOSI and MISO lines?  Very nice scope by the way, I'm afraid I only have things that shiny at work.  ;-)  We use LeCroy WaveRunners and, when budget matters, PicoScopes.  I was thinking about snagging a Picoscope for myself, as I currently just have to "trust the magic" on high speed signals.  Also check to see if you have flux built up around the IC terminals.

zador.blood.stained

zador.blood.stained

Posted
Posted
11 hours ago, TonyMac32 said:

This wouldn't be a chip-specific quirk, this would be back at the SPI driver itself, and would cause problems with any device attached to a given transmission line.  I didn't give a clean enough break between the topics, the SPI mode used, I agree, the driver should handle, but I always like to double check.  As for a needed sample delay due to routing capacitance, there is no automatic software solution that can talk to that, essentially the data received is just wrong/arbitrary, it would be a physical layer issue with the trace lengths/long parallel runs/coupling to other traces/etc.

Yeah, I must've been thinking about something else, sorry.

Kwiboo

Kwiboo

Posted
Posted
On 2017-06-26 at 5:26 PM, Xalius said:

The first step would be to see if ATF built from source works in contrats to the binary we have now, or wait for the SPL to arrive and do all at once...

 

Replacing the prebuilt rk3328_bl31_v1.34.bin with a custom built bl31.elf from latest upstream ATF source seems to work, and my device have survived past the old ~15-20 minute lockup limit.

The generated bl31.bin ends up being 4GiB for some reason, using the bl31.elf instead of bl31.bin as input to the trust_merger tool seems to work.

 

This was tested on a RK3328 tv box as my ROCK64 shipment seems to have been lost in transit :/

Kwiboo

Kwiboo

Posted
Posted
1 hour ago, Xalius said:

Did Tl send you Rock64 via EMS?

 

I think so, out of the three shipments to LibreELEC developers one made it to its destination in France last week, the second got returned by customs and my never seems to have reached Sweden at all.

But I have been told that new shipments will be made next week :)

Xalius

Xalius

Posted
  • Author
Posted
Just now, Kwiboo said:

 

I think so, out of the three shipments to LibreELEC developers one made it to France last week, the second got returned by customs and my never seems to have reached Sweden at all.

But I have been told that new shipments will be made next week :)

 

Yeah EMS is pretty hit and miss, I use them a lot when ordering stuff from AliExpress too, but it always takes 2-3weeks to Germany. They seem to have a hub in France/Paris airport and tracking always shows France as destination. Then they hand over to DHL which does the customs handling here in Germany and the delivery to my door...

Xalius

Xalius

Posted
  • Author
Posted

I did a quick test with a JMS567 and a Samsung 830 256GB SSD running iozone: 

iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

                                                     random   random
kB      reclen    write  rewrite    read    reread    read     write
102400       4    12489    13460    18838    19102    11612    13282                                                          
102400      16    40500    50855    59763    61081    36515    50299                                                          
102400     512   221087   247712   226089   236863   162081   237059                                                          
102400    1024   246648   263610   265424   276265   216642   265984                                                          
102400   16384   295448   290687   259715   344931   338378   290055 

iozone -e -I -a -s 400M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

409600       4    11139    13589    20752    24122    11615    13388                                                          
409600      16    49159    51439    61127    61224    36620    50698                                                          
409600     512   230122   246652   238314   239178   161978   246797                                                          
409600    1024   264338   276146   270927   276500   217073   277141                                                          
409600   16384   304103   305119   326587   344885   339426   300827

 

For comparison on my Thinkpad W520 (i7@3.3Ghz) with linux-deepblack 4.11.5-200.fc25.x86_64

  

                                                 random  random 
   KB  reclen   write rewrite    read    reread    read   write   
102400       4   21423   24115    28178    27733   14561   25215                                                          
102400      16   68165   74053    86389   102411   48260   73375                                                          
102400     512  138509  146013   239740   251701  176170  154234                                                          
102400    1024  169942  171816   248133   270721  213992  141895                                                          
102400   16384  179981  173118   278754   298413  302857  169050 

409600       4   21378   24261    28156    27951   14726   24664                                                          
409600      16   66187   74002    97317   101167   48185   73957                                                          
409600     512  145606  145452   253851   254371  168460  147119                                                          
409600    1024  156023  154241   282162   282168  217111  156996                                                          
409600   16384  172345  180110   299627   303149  297998  171165

 


Edit: accidentaly swapped the results while pasting, fixed now...

Xalius

Xalius

Posted
  • Author
Posted

Back to the SPI flash, I increased some debug levels in my kernel and now I got some new info, it seems that at some point the SPI DMA transfers begin to fail and then the kernel crashes....

 

http://pastebin.ubuntu.com/24997024/

 

Is it possible to disable SPI DMA transfers for testing purposes?

zador.blood.stained

zador.blood.stained

Posted
Posted
6 minutes ago, Xalius said:

Is it possible to disable SPI DMA transfers for testing purposes?

I remember reading about issues with UART DMA on the Tinkerboard, so maybe Rockchip DMA in general is partially broken?

According to Rockchip SPI DT bindings DMA properties are optional so you can try removing them, but whether it will work without DMA depends on the driver.

1
Xalius

Xalius

Posted
  • Author
Posted

@zador.blood.stained, thanks, I think this is at least a workaround, since I have no longer garbage on the flash and the kernel doesnt seem to crash anymore:

  

root@rock64:/home/rock64# ubiformat /dev/mtd0
ubiformat: mtd0 (nor), size 16777216 bytes (16.0 MiB), 4096 eraseblocks of 4096 bytes (4.0 KiB), min. I/O size 1 bytes
libscan: scanning eraseblock 4095 -- 100 % complete  
ubiformat: 132 eraseblocks have valid erase counter, mean value is 0
ubiformat: 3526 eraseblocks are supposedly empty
ubiformat: 4 corrupted erase counters
ubiformat: warning!: 434 of 4096 eraseblocks contain non-UBI data
ubiformat: continue? (y/N) y
ubiformat: warning!: only 132 of 4096 eraseblocks have valid erase counter
ubiformat: erase counter 0 will be used for all eraseblocks
ubiformat: note, arbitrary erase counter value may be specified using -e option
ubiformat: continue? (y/N) y
ubiformat: use erase counter 0 for all eraseblocks
ubiformat: formatting eraseblock 4095 -- 100 % complete  
root@rock64:/home/rock64# sudo ubiattach -m0
[  653.955360] ubi0: attaching mtd0
[  656.405192] ubi0: scanning is finished
[  656.445646] ubi0: attached mtd0 (name "spi32766.0", size 16 MiB)
[  656.446297] ubi0: PEB size: 4096 bytes (4 KiB), LEB size: 3968 bytes
[  656.447003] ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1
[  656.447686] ubi0: VID header offset: 64 (aligned 64), data offset: 128
[  656.448371] ubi0: good PEBs: 4096, bad PEBs: 0, corrupted PEBs: 0
[  656.449029] ubi0: user volume: 0, internal volumes: 1, max. volumes count: 23
[  656.449799] ubi0: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 89590605
[  656.450755] ubi0: available PEBs: 4092, total reserved PEBs: 4, PEBs reserved for bad PEB handling: 0
[  656.451754] ubi0: background thread "ubi_bgt0d" started, PID 704
UBI device number 0, total 4096 LEBs (16252928 bytes, 15.5 MiB), available 4092 LEBs (16237056 bytes, 15.5 MiB), LEB size 3968 bytes (3.9 KiB)
root@rock64:/home/rock64#

 

Xalius

Xalius

Posted
  • Author
Posted

Just moving my stuff over to eMMC now, then I'm going to try and boot something from this SPI flash... I think I'll write Kever from RK a mail and ask about what's up with DMA transfers...

Xalius

Xalius

Posted
  • Author
Posted

@TonyMac32 I have to find out, but iirc it is the same.

 

I did some more test and basic writing/reading with mtd-utils seems to work now, just read back a block after power cycling:

  

root@rock64:/home/rock64# nanddump -l500 -f test.bin /dev/mtd0                                                                                                                                                     
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 4096, page size 1, OOB size 0

Dumping data starting at 0x00000000 and ending at 0x000001f4...

root@rock64:/home/rock64# cat test.bin 

Hello World! I am a SPI Flash! This is a test!

root@rock64:/home/rock64#

 

Xalius

Xalius

Posted
  • Author
Posted

I just flashed the first 16MB from my sdcard on the SPI flash and well, it boots :-)

  

DDR version 1.06 20170424
In
SRX
LPDDR3
786MHz
Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB
ddrconfig:7
OUT
Boot1 Release Time: 2017-05-18, version: 2.43
ChipType = 0x11, 187
emmc reinit
emmc reinit
SdmmcInit=2 20
SdmmcInit=0 2
powerOn 702746
Usb re Boot. 6702743
Usb re Boot. 12702748
Usb re Boot. 18702750
SoftReset
SoftReset, 19367264 us

 

Miniloader seems to run SPI at 12Mhz, but I guess now the boot image needs tweaking since I dont see any u-boot...

1
Xalius

Xalius

Posted
  • Author
Posted

Fire219 just got his board and ran a GbE test using ayufan's latest image (only tx-offloading enabled by default) with performance governor.

  

Rock64 (client) --> Thinkcentre (server)

[  4] local 192.168.0.120 port 49148 connected to 192.168.0.85 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   104 MBytes   868 Mbits/sec    0   2.39 MBytes
[  4]   1.00-2.00   sec   108 MBytes   904 Mbits/sec    0   2.39 MBytes
[  4]   2.00-3.00   sec   108 MBytes   902 Mbits/sec    0   2.67 MBytes
[  4]   3.00-4.00   sec   108 MBytes   902 Mbits/sec    0   2.67 MBytes
[  4]   4.00-5.00   sec   105 MBytes   880 Mbits/sec    0   3.63 MBytes
[  4]   5.00-6.00   sec   110 MBytes   921 Mbits/sec    0   3.63 MBytes
[  4]   6.00-7.00   sec   105 MBytes   883 Mbits/sec    0   3.63 MBytes
[  4]   7.00-8.00   sec   110 MBytes   923 Mbits/sec    0   3.63 MBytes
[  4]   8.00-9.00   sec   106 MBytes   891 Mbits/sec    0   5.45 MBytes
[  4]   9.00-10.00  sec   106 MBytes   891 Mbits/sec    0   5.45 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.04 GBytes   896 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.04 GBytes   894 Mbits/sec                  receiver

iperf Done.

Thinkcentre (client) --> Rock64 (server)

[  4] local 192.168.0.85 port 54468 connected to 192.168.0.120 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   111 MBytes   931 Mbits/sec    0    450 KBytes
[  4]   1.00-2.00   sec   112 MBytes   941 Mbits/sec    0    474 KBytes
[  4]   2.00-3.00   sec   112 MBytes   937 Mbits/sec    0    474 KBytes
[  4]   3.00-4.00   sec   111 MBytes   929 Mbits/sec    0    474 KBytes
[  4]   4.00-5.00   sec   112 MBytes   940 Mbits/sec    0    474 KBytes
[  4]   5.00-6.00   sec   111 MBytes   933 Mbits/sec    0    474 KBytes
[  4]   6.00-7.00   sec   112 MBytes   938 Mbits/sec    0    474 KBytes
[  4]   7.00-8.00   sec   112 MBytes   942 Mbits/sec    0    474 KBytes
[  4]   8.00-9.00   sec   112 MBytes   936 Mbits/sec    0    474 KBytes
[  4]   9.00-10.00  sec   112 MBytes   936 Mbits/sec    0    474 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.09 GBytes   936 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.09 GBytes   934 Mbits/sec                  receiver

iperf Done.

 

Xalius

Xalius

Posted
  • Author
Posted

I am currently trying to patch some holes in the Rock64 dts. There seem to be some regulator properties missing and some GPIOs for card detect... I got this in the beginning:

 

http://pastebin.ubuntu.com/25013127/

 

I got rid of the "rk808 1-0018: Looking up vccX-supply property in node ..."  by defining the regulator inputs in the dts, and adding a fixed 5V regulator for DC input:

 

https://github.com/ayufan-rock64/linux-kernel/pull/3/files

 

But I have a problem now that the regulator driver can not connect the new inputs or rather created the symlinks in syfs (symptom?)

  

[    2.087955] rk808 1-0018: Pmic Chip id: 0x8050
[    2.096971] rk808 1-0018: source: on=0x40, off=0x00
[    2.108733] rk808 1-0018: Looking up vcc1-supply from device tree
[    2.108849] DCDC_REG1: supplied by vcc_sys
[    2.116743] vcc_sys: could not add device link regulator.4 err -2
[    2.118643] vdd_logic: 712 <--> 1450 mV at 1100 mV 
[    2.118947] reg-fixed-voltage sdmmc-regulator: Looking up vin-supply from device tree
[    2.118981] vcc_sd: unable to resolve supply
[    2.119009] rk808 1-0018: Looking up vcc2-supply from device tree
[    2.119100] DCDC_REG2: supplied by vcc_sys
[    2.126809] vcc_sys: could not add device link regulator.5 err -2
[    2.128223] vdd_arm: 712 <--> 1450 mV at 1000 mV 
[    2.128528] reg-fixed-voltage sdmmc-regulator: Looking up vin-supply from device tree
[    2.128559] vcc_sd: unable to resolve supply
[    2.128586] rk808 1-0018: Looking up vcc3-supply from device tree
[    2.128674] DCDC_REG3: supplied by vcc_sys
[    2.136256] vcc_sys: could not add device link regulator.6 err -2
[    2.137517] vcc_ddr: at 5000 mV 
[    2.137767] reg-fixed-voltage sdmmc-regulator: Looking up vin-supply from device tree
[    2.137797] vcc_sd: unable to resolve supply
[    2.137825] rk808 1-0018: Looking up vcc4-supply from device tree
[    2.137907] DCDC_REG4: supplied by vcc_sys
[    2.145348] vcc_sys: could not add device link regulator.7 err -2
[    2.146250] vcc_io: 3300 mV 
[    2.146552] reg-fixed-voltage sdmmc-regulator: Looking up vin-supply from device tree
[    2.146583] vcc_sd: supplied by vcc_io
[    2.154221] rk808 1-0018: Looking up vcc5-supply from device tree
[    2.154254] LDO_REG1: supplied by vcc_io
[    2.161514] vcc_io: could not add device link regulator.8 err -2
[    2.163889] vdd_18: 1800 mV 
[    2.164188] rk808 1-0018: Looking up vcc5-supply from device tree
[    2.164220] LDO_REG2: supplied by vcc_io
[    2.171394] vcc_io: could not add device link regulator.9 err -2
[    2.173749] vcc_18emmc: 1800 mV 
[    2.174041] rk808 1-0018: Looking up vcc6-supply from device tree
[    2.174072] LDO_REG3: supplied by vcc_io
[    2.181197] vcc_io: could not add device link regulator.10 err -2
[    2.183588] vdd_10: 1000 mV

 

infinity

infinity

Posted
Posted

Hi there,

since the pre-order is open now, I'm wondering whether somebody has already had a look at the power consumption? 

I'm asking because I cannot decide between 2GB and 4GB version, since I don't know how significant the increase of power consumption might be to the 4GB version.

 

My intention is to use the board as a seafile 24/7 miniserver with an SSD.  Currently a BananaPi does this task.

 

Any thoughts about this would be very appreciated :)

tkaiser

tkaiser

Posted
Posted
1 hour ago, infinity said:

somebody has already had a look at the power consumption?

 

Not really since I lack USB-to-3.5/1.35mm cables to do some precise measurements. But since we're talking about LPDDR3 here I wouldn't be concerned about the size of memory unless there's something f*cked up with entering low power states (driver issues). That's why I did no tests yet since I lack the cable and since I don't trust in software being 'stable' yet.

 

Most probably for your use case being able to choose an appropriate PSU (5V/1.5A) would save more on consumption than RAM size.

1
infinity

infinity

Posted
Posted

@tkaiser

Thanks for these suggestions! So the 3A psu and an additional usb2barrel adaptor would be a good choice. 

 

EDIT

I'm just concerned a bit about the quality of the usb2barrel adaptor cable that pine64 sells. In terms of awg standard. I'd perhaps need somewhen to extend it to 2m, which most probably wouldn't work then. 

tkaiser

tkaiser

Posted
Posted
25 minutes ago, infinity said:

So the 3A psu and an additional usb2barrel adaptor would be a good choice

 

Hmm... I think there's a misunderstanding.

 

I was only talking about my usual consumption measurements using another SBC (Banana Pro) and it's power management IC to measure its own consumption and the one of a connected other SBC (web search for 'measuring psu site:armbian.com' should give the idea). For this and only for this I would need such an USB to barrel cable, for all other use cases I would strongly recommend their 3A PSU with fixed cable.

 

Your server setup with just a single SSD might be reliably powered with only 1A (so add some peak consumption and you're at 1.5A) so if you ensure that you avoid under-voltage then you should be fine with a 1.5A PSU too. A 3A PSU is not that efficient with loads that are below 50% or even 30% of the maximum ratings so if you're after power savings you might benefit from a 'smaller' PSU. But that was only to illustrate that if you care about consumption it's most probably better to look at PSU 'size' than DRAM size ;) 

1
infinity

infinity

Posted
Posted

@tkaiser

Yep I understood it the way you meant it ;) I was just too lazy to explain that I would buy the 3A for high power and also the usb2barrel adaptor that pine64 offers for being able to use any usb phone charger at home. This way i could also connect any 1A to 2A phone charger that I have at home. 

 

Thank you very much! 

Xalius

Xalius

Posted
  • Author
Posted
9 hours ago, TonyMac32 said:

Look at rockchip patchwork area, they are adding the RK805, which I believe is the pmic involved here? They are very similar, but not quite the same.  https://patchwork.kernel.org/project/linux-rockchip/list/?q=rk805

 

Many thanks for spotting that! I think here mainline is even ahead of BSP for once, lol. I will see if I can backport the RK805 support patch for the RK808 driver, since I think atm we are just using RK808 as is with BSP... compared to A64's AXP803 this PMIC is very straightforward, the missing dts entries are more or less only cosmetics, but I like my boot logs clean :-)

Xalius

Xalius

Posted
  • Author
Posted

Some more iozone results for my JMS567 and a Samsung 830 256GB SSD running iozone, using large size of 12GB shows some significantly different results to the values above with 100M, 400M. 

  

                                                      random    random
      kB  reclen    write  rewrite    read    reread    read     write
12288000       4    17768    22328    26129    25677    13302    21361                                                          
12288000      16    61171    75520    79985    79982    43520    73117                                                          
12288000     512   157411   241636   297964   297923   186737   107077                                                          
12288000    1024   179415   259620   308459   320070   239986   166616                                                          
12288000   16384   195302   232991   335103   352457   345601   153506

 

It would be interesting to see some low level statistics on the USB/UAS transfers...

infinity

infinity

Posted
Posted

Seeing these USB benchmarks: Is anything known about USB3-Hub support? Since the board has only one USB3 port, It'd be interesting to know what happens if you add an USB3 Hub to connect more than one device. Also wondering what would happen with UAS support if such a hub-setup is possible.

Xalius

Xalius

Posted
  • Author
Posted

That is an interesting question, I have one USB3 hub at home, maybe I'll get a second JMS bridge and find out...

1
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept