ROCK64

[martinayotte]

Welcome !

I had to manually use parted and resize2fs to get all it's space ...

 

[TonyMac32]

That extra 10/100 ethernet seems like a good place to put an HDHomerun if you were running a TVHeadend server...

[pfeerick]

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!  

 

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

 

 

 

[martinayotte]

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.

[Kwiboo]

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

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

 

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.

[Xalius]

Ayufan currently uses the partitioning scheme that is created by the https://github.com/rockchip-linux/build system too...

 

(https://github.com/ayufan-rock64/linux-build/releases)

[TonyMac32]

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)

[Xalius]

How good does the GbE interface on Tinkerboard work? On Rock64 there are big variances in GbE performance atm, but we have not tuned anything yet...

[TonyMac32]

@Xalius  

 

[zador.blood.stained]

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?  I'm assuming one of these tools adds sime kind of a signature for the BootROM and also may add some checksums.

[Xalius]

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?

[TonyMac32]

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

[hojnikb]

any word on pricing ?

[Xalius]

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

[martinayotte]

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 ?

[TonyMac32]

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"...  

[Kwiboo]

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?  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.

[TonyMac32]

Did not take a long look at it, but https://github.com/rockchip-linux/rkdeveloptool

[Xalius]

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?

[zador.blood.stained]

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.

[umiddelb]

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

 

[Xalius]

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

[TonyMac32]

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 

[Xalius]

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

[hojnikb]

Any word on pricing yet ?

[zador.blood.stained]

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 June 30, 2017 by zador.blood.stained
Clarify that this is from public IRC logs

[hojnikb]

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

[Xalius]

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

[zador.blood.stained]

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?

[Xalius]

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