Jump to content
  • 0

ROCK64


Xalius
 Share

Question

Moderator edit (pfeerick): I have modified this post to contextualise this split thread. It was initially intended to be a discussion of a board bring up procedure / proposal format, and has since evolved into discussion of the rock64 generally. 

 

Xalius originally said in this post: 

TODO-List sounds good to me, I will run some tests as soon as China Post/DHL actually deliver my package. I get a 4GB version with the suppressor diodes for USB3 already replaced...

 

This is what tkasier originally wrote in his first post, minus the disclaimer as was only relevant to that thread:

 

Quote

 

Let me introduce ROCK64:

 

  • RK3328 SoC: feature list
  • ROCK64 schematic (preliminary since vendor promised to accept last minute changes/suggestions within the 2 next weeks)
  • Board layout picture (same form factor as Raspberries, pre-production samples do not fit exactly in RPi enclosures, final design should fit)
  • 1GB, 2GB or 4GB PC-18666 LPDDR3
  • eMMC has higher boot priority than SD card (but eMMC can be disabled via jumper)
  • socketed eMMC modules are the same as on Pinebook and SoPine (and compatible to older ODROIDs and their SD card adapter)
  • 128Mb SPI NOR flash (16MB) on future board revisions (to directly boot from USB[3] storage, network or whatever)
  • RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth)
  • Due to USB3, GbE and additional Fast Ethernet also interesting for NAS/server use cases (TBC, both USB3 and GbE performance needs to be checked)
  • I2S exposed and compatible to some early RPi DACs, a lot more GPIOs exposed as usual (see picture above and this)
  • Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks)

 

Pros:

  • board vendor actively participates (listens to community, provides information including schematic and cares about correctness, tries to bridge developer community and chip vendor)
  • board vendor provides dev samples and documents problems devs might run into (see below)
  • chip vendor actively supports mainline Linux and u-boot
  • chip vendor is said to focus on ROCK64 as currently best supported RK3328 device to spread market adoption (TBC)
  • SDK/BSP not horribly outdated (RK relies currently on 4.4)
  • almost all Armbian target audiences might benefit from RK3328 support (desktop replacement, NAS/server, audiophiles + IoT use cases due to exposed GPIOs/interfaces)
  • No unreliable shitty Micro USB for DC-IN but sane 3.5/1.35mm barrel plug to be combined with 5V/3A PSU Pine Inc already sells together with Pinebook
  • Icenowy already received a dev sample ;)

 

Cons:

 

  • new platform (Rockchip 64-bit) needing more initial work

 

Did anyone of you received shipping confirmation with tracking number already? @jernej? Unfortunately I get a dev sample with unusable USB3 (some components need to be desoldered which is a pity since I'm not good in soldering at all)

 

My next steps planned:

 

  • Boot the board with what's provided within one week (TL Lim mentioned a 'Debian based 4.4 BSP, later Yocto' and said RK would be ready with a mainline variant within the next weeks)
  • Test GbE speeds, memory throughput and the usual Armbian tunables (IRQ distribution)
  • ask @Xaliusfor USB3 numbers (his dev sample was shipped out later and doesn't need soldering)
  • Present results to continue discussion

 

 

Link to comment
Share on other sites

Recommended Posts

Armbian Linux community supported weekly builds download

  • 0
9 hours ago, martinayotte said:

I've copied the same xenial mate into eMMC, tweak the /boot/extlinux/extlinux.conf to point to mmcblk1, and now it boot from eMMC.

 

 

Woohoo! Nice to know it will that easy... my chinglish android eEMMC install might die a sudden death now and be reborn with linux... after a backup, of course! ;) I still find the android OS handy for usage as dumb TV box! :)

 

This is the pinout document for the rock64 - hopefully it's all correct! :o 

 

The boot sequence on the RK3328 is external eMMC, SPI Nor Flash, SPI Nand Flash(not fitted to rock64), external SDMMC card, USB (FEL/OTG). So unfortunately eMMC before SD :(

 

I hate to ruin my uptime of  1 day,  4:16,  2 users,  load average: 0.00, 0.00, 0.00, but needs must. I usually use the eMMC jumpter to boot from the SD instead of the eMMC, but I just unplugged the eMMC, removed the jumper, and tried a clean boot of the rock64, and it's up again, so I'm not sure what's going in with yours not booting when you have the eMMC removed and not booting from the microSD. This is with the 2GB model. 

 

As far as the partition layout,  mine (running 0.2.0) is:

 

Spoiler

Disk /dev/mmcblk0: 29.8 GiB, 32010928128 bytes, 62521344 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 98C438D0-B528-49FA-834D-91E86BA4E3E7

Device          Start     End Sectors  Size Type
/dev/mmcblk0p1     64    8063    8000  3.9M Linux filesystem
/dev/mmcblk0p2   8064    8191     128   64K Linux filesystem
/dev/mmcblk0p3   8192   16383    8192    4M Linux filesystem
/dev/mmcblk0p4  16384   24575    8192    4M Linux filesystem
/dev/mmcblk0p5  24576   32767    8192    4M Linux filesystem
/dev/mmcblk0p6  32768  262143  229376  112M Linux filesystem
/dev/mmcblk0p7 262144 2359295 2097152    1G EFI System

 

 

 

Link to comment
Share on other sites

  • 0
6 hours ago, pfeerick said:

android eEMMC install might die a sudden death now and be reborn with linux... after a backup, of course

I didn't take care of backuping mine ... ;)

 

6 hours ago, pfeerick said:

I usually use the eMMC jumpter to boot from the SD

It is what I did but removed the jumper only 1 or 2 secs after bootloader started.

Link to comment
Share on other sites

  • 0
On 2017-06-24 at 8:10 PM, martinayotte said:

Is that 7 GPT partitions scheme is normal ? (we are not on Android here ... :wacko:)

 

You should be able to use whatever partition table and filesystem as long as u-boot can recognize it and finds a bootable partition with the extlinux/extlinux.conf file.

That is if you use the 'release' branch from https://github.com/rockchip-linux/u-boot, if you use the Android 'rkproduct' branch it have special needs...

 

For the LibreELEC Rockchip endeavor we currently use a MBR partition table with a bootable fat partition and a second ext4 storage partition, but will probably switch to a GPT partition table in next update.

We also make the first partition start at 16MiB to match https://github.com/rockchip-linux/build images.

Link to comment
Share on other sites

  • 0

Assuming the rk3328 maskrom is similar to the rk3288, @Kwiboo is mostly correct.  There are a couple magic values, the U-boot SPL, and a device tree that get located before the main U-boot is loaded, but the maskrom uses hardware block device addressing, it does not use the partition table.  Now, with the SPI memory this changes.  Then, whatever U-boot can see it can load after the maskrom loads U-boot from that chip (if loaded/enabled)

Link to comment
Share on other sites

  • 0
Quote

Assuming the rk3328 maskrom is similar to the rk3288, @Kwiboo is mostly correct.  There are a couple magic values, the U-boot SPL, and a device tree that get located before the main U-boot is loaded, but the maskrom uses hardware block device addressing, it does not use the partition table.  Now, with the SPI memory this changes.  Then, whatever U-boot can see it can load after the maskrom loads U-boot from that chip (if loaded/enabled)

 

I'm more interested in determining what is combined and how for the u-boot image.

ATF - even though upstream ATF has rk3328 support, I'm assuming Rockchip's binary version is using a different code base. Is it open source (i.e. this repo) and what branch should be used then?

SPL - is it possible to use u-boot SPL with FIT support and what will be the configuration for it?

DRAM init - looks like a blob with no sources, how is it linked and called?

rkbin tools - no sources? seriously? :angry: I'm assuming one of these tools adds sime kind of a signature for the BootROM and also may add some checksums.

Link to comment
Share on other sites

  • 0

They recently added some u-boot patches for dram config on RK3328 to the BSP repo and promised to release SPL soon. 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...

 

@TonyMac32, is there a complete schematic of Tinkerboard somewhere? I looked at the one from the ASUS download section but it seems incomplete?

Link to comment
Share on other sites

  • 0
25 minutes ago, TonyMac32 said:

That's as good as it gets.  One of my (many) gripes.  Calling it "incomplete" is actually very kind.  It's crap.

 

Yeah, there are lots of blocks from the RK3288 standard schematic missing completely, I wanted to see how they wired up GbE and the delay line config... 

Link to comment
Share on other sites

  • 0
1 hour ago, TonyMac32 said:

There are a couple magic values, the U-boot SPL, and a device tree that get located before the main U-boot is loaded, but the maskrom uses hardware block device addressing, it does not use the partition table

Those that means that we can later have a 1 partition scheme instead of this ugly 7 one ?

Link to comment
Share on other sites

  • 0

For the rk3288 boards we do, I don't see why we couldn't here as well.

 

Rockchip's info on booting  http://opensource.rock-chips.com/wiki_Boot_option

 

Our script:  https://github.com/armbian/build/blob/master/config/sources/rockchip.conf

 

http://opensource.rock-chips.com/wiki_U-Boot  claims upstream support for the SoC.  Hmmm, also claims support for the "Miniarm" and the "ASUS Tinker"...  :rolleyes:

Link to comment
Share on other sites

  • 0
1 hour ago, zador.blood.stained said:

I'm more interested in determining what is combined and how for the u-boot image.

ATF - even though upstream ATF has rk3328 support, I'm assuming Rockchip's binary version is using a different code base. Is it open source (i.e. this repo) and what branch should be used then?

SPL - is it possible to use u-boot SPL with FIT support and what will be the configuration for it?

DRAM init - looks like a blob with no sources, how is it linked and called?

rkbin tools - no sources? seriously? :angry: I'm assuming one of these tools adds sime kind of a signature for the BootROM and also may add some checksums.

 

Until Rockchip finished the SPL+DRAM init code for RK3328 we have to use the ddr+miniloader blobs to start u-boot, https://github.com/rockchip-linux/build/blob/debian/mk-uboot.sh#L48-L77 generates working idbloader.img, uboot.img and trust.img using tools and blobs from the rkbin repo.

The BootROM will look for idbloader.img at 0x40 on SPI/eMMC/SD, and the miniloader will expect uboot.img+trust.img at 0x4000 and 0x6000 on the same device it loaded idbloader.img from, the miniloader before v2.43 had a bug that would always load uboot+trust from eMMC (or possibly SPI).

http://opensource.rock-chips.com/wiki_Boot_option have some details on the boot process.

Link to comment
Share on other sites

  • 0

I am just trying to see if I can set up the SPI flash on the Rock64 as an mtd(block) device. I enabled the SPI node in the dts and made a new kernel with mtd layer enabled. Now I have to see what else is needed. It looks like I need to either describe the flash in devicetree or pass that info to the kernel on boot... has anyone before configured an SPI flash as mtd device?

Link to comment
Share on other sites

  • 0
11 minutes ago, Xalius said:

has anyone before configured an SPI flash as mtd device?

Yes, for example like this: https://github.com/armbian/build/blob/master/patch/kernel/sun50i-dev/add-spi-flash-pc2.patch

Generic bindings docs: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt

 

Edit:

Adding partitions via DT: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/devicetree/bindings/mtd/partition.txt

 

Edit 2:

Forgot to say, just to be clear - partitions are optional, whole flash will be mapped as one MTD device without them, and alternatively there is a kernel config symbol CONFIG_MTD_PARTITIONED_MASTER to add a device node for the whole flash when it is partitioned.

Link to comment
Share on other sites

  • 0

just pass the mtd partition information as a parameter on the kernel cmdline (after having looked up them in the u-boot sources), e.g. for the ESPRESSObin:

mtdparts=spi0.0:1536k(uboot),64k(uboot-environment),-(reserved)

Cheers

Uli

 

Link to comment
Share on other sites

  • 0

Ok, I added a flash node inside the spi node for the flash with a driver that should work since the basic flash commands seem to be the same:

 

        spi@ff190000 {
                compatible = "rockchip,rk3328-spi", "rockchip,rk3066-spi";
                reg = <0x0 0xff190000 0x0 0x1000>;
                interrupts = <0x0 0x31 0x4>;
                #address-cells = <0x1>;
                #size-cells = <0x0>;
                clocks = <0x2 0x20 0x2 0xd1>;
                clock-names = "spiclk", "apb_pclk";
                dmas = <0xb 0x8 0xb 0x9>;
                #dma-cells = <0x2>;
                dma-names = "tx", "rx";
                pinctrl-names = "default";
                pinctrl-0 = <0x30 0x31 0x32 0x33>;
                status = "okay";

                w25q128@0 {
                        #address-cells = <0x1>;
                        #size-cells = <0x0>;
                        compatible = "winbond,w25q128", "jedec,spi-nor";
                        reg = <0x0>;
                        spi-max-frequency = <40000000>;
                        status = "okay";
                };

        };

 

That gives me:

 

rock64@rock64:~$ dmesg | grep spi
[    1.172285] m25p80 spi32766.0: w25q128 (16384 Kbytes)

rock64@rock64:/dev$ mtdinfo 
Count of MTD devices:           1
Present MTD devices:            mtd0
Sysfs interface supported:      yes

rock64@rock64:/proc$ sudo flash_erase /dev/mtd0 0 0
Erasing 64 Kibyte @ ff0000 -- 100 % complete 

rock64@rock64:~$ sudo dd if=/dev/mtd0 of=test.bin status=progress
16642560 bytes (17 MB, 16 MiB) copied, 30.0011 s, 555 kB/s 
32768+0 records in
32768+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 30.4636 s, 551 kB/s

So I guess something works...

 

Edit: The MTD device hangs at random points during write/read operations, I tried to create an ubi volume for testing purposes, but formatting the flash just hangs during the process...

 

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: 1 eraseblocks are supposedly empty
ubiformat: warning!: 4095 of 4096 eraseblocks contain non-UBI data
ubiformat: continue? (y/N) y
ubiformat: warning!: only 0 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 477 -- 11 % complete

 

I tried to reduce SPI clock to 25Mhz bus still hangs at random points...

Link to comment
Share on other sites

  • 0

That winbond chip is advertised as support SPI mode 0 and 3.  Can you verify that's what the driver is doing?  You may want to look at adding some sample delay to the SPI node, in case of capacitive load on the transmission lines.

 

rx-sample-delay-ns

After using SPI on really dumb micros, I have no love of setting it up  ;)

Link to comment
Share on other sites

  • 0
1 hour ago, hojnikb said:

Any word on pricing yet ?

From IRC logs:

Quote
2017-06-26 18:02:54 <tllim_> the 4GB ROCK SBC price (at leats for first batch) able to roll out for $44.95 
2017-06-26 18:08:18 <tllim_> we will decide tonight on the ROCK64 LPDDR3 SDRAM PC-1600 vs PC-1866. If using PC-1600, this price is 1GB - $24.95, 2GB - $34.95, 4GB - $44.95
2017-06-27 17:11:45 <tllim> using 4GB ROCK64 as example. If select PC-1600, the pric can be in $44.95. However if goes for PC-1866, the price will need to adjust to around $58-$59. 

Please keep in mind that AFAIK it was not announced yet officially.

 

Edit:

And please don't repeat the same question too often.

 

 

Edited by zador.blood.stained
Clarify that this is from public IRC logs
Link to comment
Share on other sites

  • 0
2 hours ago, zador.blood.stained said:

From IRC logs:

Please keep in mind that AFAIK it was not announced yet officially.

 

 

 

 

 

Thank you for the info.

 

Quote

 

Edit:

And please don't repeat the same question too often.

 

 

Duly noted :)

Link to comment
Share on other sites

  • 0
8 hours ago, TonyMac32 said:

That winbond chip is advertised as support SPI mode 0 and 3.  Can you verify that's what the driver is doing?  You may want to look at adding some sample delay to the SPI node, in case of capacitive load on the transmission lines.

 


rx-sample-delay-ns

After using SPI on really dumb micros, I have no love of setting it up  ;)

 

I checked the datasheet and it says "Clock low to output valid = 7ns max." I'll try some settings in that range and see if it changes anything..

Link to comment
Share on other sites

  • 0
3 hours ago, Xalius said:

I checked the datasheet and it says "Clock low to output valid = 7ns max." I'll try some settings in that range and see if it changes anything..

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"

 

8 hours ago, Xalius said:

Yes I think I will break out the scope and look what the signals and timing looks like...

And also is there any data exchange while the operation is "stuck" (ideally it would be best to use a logic analyzer and capture the traffic to see what's going on)

 

19 hours ago, Xalius said:

Edit: The MTD device hangs at random points during write/read operations, I tried to create an ubi volume for testing purposes, but formatting the flash just hangs during the process...

Also is there anything suspicious in dmesg?

Link to comment
Share on other sites

  • 0

It took me a little to get the scope set up but I looked at the analog waveforms first and they did not look too bad. There was some overshoot at 40Mhz but that could also be due to my probe setup and cabling, I reduced SPI clock to 25Mhz for now...  Looking at the bus with the logic analyzer nothing seems really off at first glance, but I have too look at the details now. My kernel crashed once or twice during long transactions, so it could also be another problem buried in there.... nothing in dmesg besides that...

 

 

 

 

IMG_20170630_220431.jpg

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...