Jump to content
  • 0

Rock64pro

Bekim Lutolli

Asked by Bekim Lutolli,

 Share

Question

Bekim Lutolli

Bekim Lutolli

Posted
Posted

Hi,

i would like to know if there will be armbian stretch for rock64pro. I tried images on official website, but there are all with alot of buggs + they have everything messed up with user.

I need that clean new image for emmc card. I would start from basic debian stretch image, but i couldnt make it work with etcher.

 

p.s. sorry for my bad English, this is not my native language

 

Best regards, Bekim

Link to comment
Share on other sites

55 answers to this question

Recommended Posts

  • 0
Igor

Igor

Posted
Posted

We had to put bootloader together and according to this official Rockchip documentation, I can't get to the usable bootloader or I don't see it right. Everything else is prepared, several RK3399 boards run fine, also Firefly 3399.

 

I am currently busy with other things.

 

Perhaps @pfeerick or @ayufan might shed some light?

Currently, this part is missing:

https://github.com/armbian/build/blob/master/config/sources/rockchip64.conf#L82
and the following are my tries which don't work: 

uboot_custom_postprocess()
tools/mkimage -n rk3399 -T rksd -d $SRC/cache/sources/rkbin-tools/rk33/rk3399_ddr_933MHz_v1.13.bin idbloader.bin
tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl.bin idbspl.img
cat idbspl.img >> idbloader.img
loaderimage --pack --uboot ./u-boot.bin uboot.img

write_uboot_platform()
dd if=idbloader.bin of=SDCARD seek=64 conv=notrunc status=none
dd if=uboot.img of=SDCARD seek=16384 conv=notrunc status=none
dd if=trust.bin of=SDCARD seek=24576 conv=notrunc status=none

 

Link to comment
Share on other sites

Search Before Posting!

  • 0
chwe

chwe

Posted
Posted
On 9/22/2018 at 8:19 PM, martinayotte said:

U-Boot which freeze after DDR init, without any prompt.

does it end somewhere here?  

RunBL31 0x10000
NOTICE:  BL31: v1.3(debug):f947c7e
NOTICE:  BL31: Built : 19:47:19, Sep 13 2018
NOTICE:  BL31: Rockchip release version: v1.1
INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO:    plat_rockchip_pmu_init(1089): pd status 3e
INFO:    BL31: Initializing runtime services
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9

so shortly before it enters u-boot?

Link to comment
Share on other sites
  • 0
martinayotte

martinayotte

Posted
Posted
19 hours ago, chwe said:

does it end somewhere here? 

 

Not exactly ... It seems to stop few lines earlier in trust.bin ...

 

 

 


OUT
Boot1: 2018-08-06, version: 1.15
CPUId = 0x0
ChipType = 0x10, 218
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
SdmmcInit=2 1
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=29664MB
FwPartOffset=2000 , 0
StorageInit ok = 56377
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
GPT 0x3190d20 signature is wrong
LoadTrust Addr:0x4000
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0xa2144
RunBL31 0x10000
NOTICE:  BL31: v1.3(debug):f947c7e
NOTICE:  BL31: Built : 16:24:02, Aug 26 2018
 

 

 

I will try to port the u-boot used in NanoPCT4, since it seems to use v2018.09 instead of rockchip branch, which is a lot better for future maintenance ...

 

EDIT: I'm missing something ... :( I've ported patches to get U-Boot from v2018.09, and it still freeze at the same place ... :(

Link to comment
Share on other sites
  • 0
chwe

chwe

Posted
Posted

@ayufans u-boot doesn't have RAM defined in DT (compared to other RK3399 boards). I don't think this kicks in that early, but it was the first thing I saw by compare it with others...

Notebook died today, so I'm out for a few days... 

Looks you're still in 'ATF world' but ATF is still a mistery to me..  😂 did you check/compare atf sources as well?

Link to comment
Share on other sites
  • 0
martinayotte

martinayotte

Posted
Posted
47 minutes ago, chwe said:

Looks you're still in 'ATF world' but ATF is still a mistery to me..  😂 did you check/compare atf sources as well?

In Armbian build process, both u-boot-rk3399 and u-boot-rockchip trees are sharing the same arm-trusted-firmware-rockchip64 tree.

It is a bit a mystery for me too, I'm more used to AllWinner ones ...

Link to comment
Share on other sites
  • 0
TonyMac32

TonyMac32

Posted
Posted

I've started poking at this, I missed the conversation, to fill in more for the U-boot plumber @chwe:

 

Output of what the build system currently creates:

  

DDR Version 1.13 20180801
In

So that is quite obviously missing the entire loader portion of the equation, simply the RAM part is alive (maybe freezing, unknown exactly)

 

My observation:

 

On 9/10/2018 at 4:28 PM, Igor said:

and the following are my tries which don't work: 


uboot_custom_postprocess()
tools/mkimage -n rk3399 -T rksd -d $SRC/cache/sources/rkbin-tools/rk33/rk3399_ddr_933MHz_v1.13.bin idbloader.bin
tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl.bin idbspl.img
cat idbspl.img >> idbloader.img
loaderimage --pack --uboot ./u-boot.bin uboot.img

write_uboot_platform()
dd if=idbloader.bin of=SDCARD seek=64 conv=notrunc status=none
dd if=uboot.img of=SDCARD seek=16384 conv=notrunc status=none
dd if=trust.bin of=SDCARD seek=24576 conv=notrunc status=none

 

 

The idbspl.img and idbloader.bin are mutually exclusive, the Rockchip documentation is a little sloppy on that.  So this is trying to handle two separate and incompatible boot paths simultaneously ("Path4" is not too well defined, but is relatively blob-free I think, but my tries with it didn't fo anything at all...  :lol:)

 

My tries so far got me to:

Spoiler 

DDR Version 1.13 20180801
In
Channel 0: LPDDR4,50MHz
CS = 0
MR0=0x98
MR4=0x3
MR5=0xFF
MR8=0x8
MR12=0x4D
MR14=0x4D
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB
Channel 1: LPDDR4,50MHz
CS = 0
MR0=0x98
MR4=0x3
MR5=0xFF
MR8=0x8
MR12=0x4D
MR14=0x4D
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB
256B stride
channel 0
CS = 0
MR0=0x98
MR4=0x3
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x98
MR4=0x3
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 400MHz 0,1
channel 0
CS = 0
MR0=0x98
MR4=0x81
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x98
MR4=0x3
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 800MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x20
ch 1 ddrconfig = 0x101, ddrsize = 0x20
pmugrf_os_reg[2] = 0x3281F281, stride = 0x9
OUT
Boot1: 2018-04-08, version: 1.12
CPUId = 0x0
ChipType = 0x10, 219
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
SdmmcInit=2 1
mmc0:cmd5,32
SdmmcInit=0 0
BootCapSize=0
UserCapSize=60906MB
FwPartOffset=2000 , 0
StorageInit ok = 69892
LoadTrustBL
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x60000000, size=0xa1d30
RunBL31 0x10000
NOTICE:  BL31: v1.3(debug):f947c7e
NOTICE:  BL31: Built : 22:57:21, Oct 31 2018

 

...and it hangs.  So I think the missing "0x200000" on the loaderimage may be partially to blame. 

 

[edit] well, load address changed, but still a hang at BL31 statement.  I think @chwe is on to the answer. <--- Nope.

Link to comment
Share on other sites
  • 0
TonyMac32

TonyMac32

Posted
Posted

I'm about 75% sure it's the defconfig for the board in u-boot, it has environment and such coming off of the SPI flash, and has a bunch of Android boot stuff enabled that the nanopi's does not.  Tried playing with it in the rockchip folder but it started having compile issues.  Otherwise U-boot should at least try to load, the system does not care what board it is living on as long as the RAM is working until it loads the actual uboot image.

 

RK ---> RAM +  miniloader --> u-boot/trust.  We have the miniloader running, up until it goes to grab the u-boot image, then it falls on its face.  I'll try it with mainline u-boot tomorrow, and use a more generic defconfig that is pointing in the right directions

 

Link to comment
Share on other sites
  • 0
TonyMac32

TonyMac32

Posted
Posted

No problem.  My thought here is, if there were something fundamentally wrong with the RAM no one could boot these boards anywhere.  And up until you load u-boot only the RAM and SoC are "alive", so all of these boards should behave nearly identically up until you load the u-boot image, so the problem is most likely there.  We have some issues with the post-process I'll commit later, with them resolved you get to the point of loading the bl31 every time (limited number of tries)

Link to comment
Share on other sites
  • 0
chwe

chwe

Posted
Posted
15 hours ago, TonyMac32 said:

Channel 0: LPDDR4,50MHz

really? 50MHz? sounds fishy.. :D

 

did you have a look into this one:

https://github.com/ayufan-rock64/linux-u-boot/blob/d646df03ace3bd191e24361944ce1c7ef3c8744c/configs/rockpro64-rk3399_defconfig#L16

e.g. upstream u-boot points to a python script, which is not board but soc specific:

https://github.com/u-boot/u-boot/blob/master/configs/evb-rk3399_defconfig#L16

 

not sure if we knock out it fully when we write u-boot...

 

this one may also be interesting..

https://github.com/ayufan-rock64/linux-u-boot/blob/rockchip-master/board/rockchip/rockpro64_rk3399/rockpro64-rk3399.c

Link to comment
Share on other sites
  • 0
TonyMac32

TonyMac32

Posted
Posted
14 minutes ago, chwe said:

really? 50MHz? sounds fishy.. :D

 

Read further, it's some kind of boot testing.  It jumps to 400 then 800 with the 800 MHz binary, I've gone back to the 933MHz binary as used in the Ayufan repo.

 

I compared the scripts, they appear the same, but with so much going on variable wise it's hard to say.  Part of why I want to reattempt mainline.  

 

I've done diffs on all the various files looking for a "smoking gun", I have a few directions, but the defconfig is the biggest one.

Link to comment
Share on other sites
  • 0
chwe

chwe

Posted
Posted
Just now, TonyMac32 said:

Read further, it's some kind of boot testing.

I may have to purge first my chemistry mindset before I'm really helpful here.. :lol: Similar issues with my H96max a like TV-box board..

well, gonna be a mess to sort out whitch bits are missing. :P

 

Link to comment
Share on other sites
  • 0
giminni

giminni

Posted
Posted

Hi all ,

 

I built a development RockPro64 image and attached the serial console.

After booting the sdHC card I got stuck at:

 

Quote

...

Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0xa1d30
RunBL31 0x10000
NOTICE:  BL31: v1.3(debug):f947c7e
NOTICE:  BL31: Built : 01:54:58, Nov 24 2018

 

Can someone enlighten me what is wrong with BL31?

 

Apparently the u-boot loader was OK, found BL31.

Is somewhere a brief explanation what the steps of booting a RockPro64 image are and what is involved in this process. (bootloader, BL31, kernel, ...)

> https://github.com/u-boot/u-boot/tree/master/board/rockchip/evb_rk3399

 

I found an interesting entry about reformatting the partitions after dd'ing
> https://forum.pine64.org/archive/index.php?thread-5210.html

 

could this be the root cause of it?


Thanks a lot!
 

Link to comment
Share on other sites
  • 0
giminni

giminni

Posted
Posted

Correct me If I am wrong, what I understood from the U-boot and Rockchip boot documentation is:

- There are two flows:

   - (Flow 1) with rockchip miniloader with and without atf-image  (the armbian way)

   - (Flow 2) with uboot-SPL/TPL with and without atf image (with FIT script) (the ayufan way)

 

In our case we use Flow 1

- for sdHC card boot we need different images for each boot stage:

   - idbloader.img (Boot stage 2)

   - uboot.img (Boot stage 3)
   - trust.img (Boot stage 3)
   - boot.img (Boot stage 4)
   - rootfs.img (Boot stage 5)

 

Here the recommended rockchip procedure:

Quote

tools/mkimage -n rkxxxx -T rksd -d rkxx_ddr_vx.xx.bin idbloader.img

cat rkxx_miniloader_vx.xx.bin >> idbloader.img

cp arm-trusted-firmware/build/rk3399/release/bl31.elf rkbin/rk33

./rkbin/tools/trust_merger rkbin/tools/RK3399TRUST.ini

./rkbin/tools/loaderimage --pack --uboot u-boot/u-boot-dtb.bin uboot.img 0x200000

 

Quote

# Boot stage 2 (with rk miniloader) as loader 1

dd if=idbloader.img of=sdb seek=64

# Boot stage 3 (u-boot) as loader 2

dd if=uboot.img of=sdb seek=16384

# Boot stage 3 (atf)

dd if=trust.img of=sdb seek=24576

# Boot stage 4 (kernel/zImage)

dd if=boot.img of=sdb seek=32768

# Boot stage 5 (distro)

dd if=rootfs.img of=sdb seek=262144

 

- the recommended GPT partition layout is:

  

Partition			Hex-Offset	Size	Boot	Type
==================================================================================
MBR 				00000000 	0.5KB 	  	 
Primary GPT 			00000001 	31.5KB 	  	 
loader1 			00000040 	2.5MB 	1 	preloader (miniloader or U-Boot SPL)
Vendor Storage 			00001c00 	256KB 	  	SN, MAC and etc.
Reserved Space 			00001e00 	192KB 	  	Not used
reserved1 			00001f80 	64KB 	  	legacy DRM key
U-Boot ENV 			00001fc0 	32KB 	  	 
reserved2 			00002000 	4MB 	  	legacy parameter
loader2 			00004000 	4MB 	2 	U-Boot or UEFI
trust 				00006000 	4MB 	3 	trusted-os like ATF, OP-TEE
boot（set bootable） 		00008000 	112MB 	4 	kernel, dtb, extlinux.conf, ramdisk
rootfs 				00040000 	-MB 	5 	Linux system

Following ayufan's layout, uboot and rockchip advise we could:
Example below is not precise enough but give an idea how to do it...

Quote

# Create partitions

echo "Updating GPT..."

parted -s "${TEMP_IMAGE}" mklabel gpt

parted -s "${TEMP_IMAGE}" unit s mkpart loader1 64 8063 # 4MB

parted -s "${TEMP_IMAGE}" unit s mkpart reserved1 8064 8191 # 4MB

parted -s "${TEMP_IMAGE}" unit s mkpart reserved2 8192 16383 # 4MB

parted -s "${TEMP_IMAGE}" unit s mkpart loader2 16384 24575 # 4MB

parted -s "${TEMP_IMAGE}" unit s mkpart atf 24576 32767 # 4MB

parted -s "${TEMP_IMAGE}" unit s mkpart boot fat16 32768 262143 # 128MB

parted -s "${TEMP_IMAGE}" unit s mkpart root ext4 262144 100% # rest

parted -s "${TEMP_IMAGE}" set 7 legacy_boot on

 

# Create images

tools/mkimage -n rkxxxx -T rksd -d rkxx_ddr_vx.xx.bin idbloader.img

cat rkxx_miniloader_vx.xx.bin >> idbloader.img

cp arm-trusted-firmware/build/rk3399/release/bl31.elf rkbin/rk33

./rkbin/tools/trust_merger rkbin/tools/RK3399TRUST.ini

./rkbin/tools/loaderimage --pack --uboot u-boot/u-boot-dtb.bin uboot.img 0x200000

 

# Deploy with miniloader

rkdeveloptool db rkxx_loader_vx.xx.bin

rkdeveloptool ul rkxx_loader_vx.xx.bin

rkdeveloptool wl 0x4000 uboot.img

rkdeveloptool wl 0x6000 trust.img

rkdeveloptool wl 0x8000 boot.img

rkdeveloptool wl 0x40000 rootfs.img

rkdeveloptool rd

 

This make sense to me and at the end we have:
For sdHC cards X=1, eMMC X=0: <- not shure
mmcblkXp6 - boot (with extlinux) and

mmcblkXp7 - rootfs (linux distro)

 

 


Why is the armbian's layout building only one partition?
 

Link to comment
Share on other sites
  • 0
martinayotte

martinayotte

Posted
Posted
19 minutes ago, giminni said:

Why is the armbian's layout building only one partition?

Mostly because we hate having a small boot partition that can become full when upgrading kernel.

 

But here, you are mixing the RK3399 bootloader sectors with partitions.

Just to let you know, I'm still struggling to have u-boot working the way Armbian is doing, but it is not ready yet.

I've also looking the way Ayufan is doing, but didn't get it either yet ...

 

BTW, using Ayufan u-boot binary itself, I can boot without issue, even if Armbian has only 1 partition for RootFS.

 

If you are interested, simply grab Ayufan u-boot sectors from one of his recent image, and overwrite the on on Armbian images, you will see that it is working perfectly ...

 

Link to comment
Share on other sites
  • 0
giminni

giminni

Posted
Posted
7 hours ago, martinayotte said:

BTW, using Ayufan u-boot binary itself, I can boot without issue, even if Armbian has only 1 partition for RootFS.

 

If you are interested, simply grab Ayufan u-boot sectors from one of his recent image, and overwrite the on on Armbian images, you will see that it is working perfectly ...

 

Hmm, strange why not try boot flow 2 (SPL/TPL)?

Link to comment
Share on other sites
  • 0
martinayotte

martinayotte

Posted
Posted
15 hours ago, giminni said:

Great, can you tell me what you have done?

What I found by digging Ayufan build script and comparing Rockchip Wiki, is that Ayufan doesn't place the u-boot-itb at sector 0x4000, but at sector 0x200, probably to avoid waste of space ...

11 hours ago, TonyMac32 said:

I'll take another round with it as well if you provide examples.

I'm about to do final commit in Armbian script, you will then have to simply do a build of the image.

 

11 hours ago, TonyMac32 said:

Even if we get "flow 2" working

My commit will use "flow #2", but maybe the glitch in "flow #1" is maybe related to sector location too ...

 

EDIT : Here is the commit https://github.com/armbian/build/commit/c3e46a5d863ebc4d00d666b3a19eed00e3d0c17d

 

EDIT2 : I've tested the "nand-sata-install" on eMMC, and it is working fine too ...

2
Link to comment
Share on other sites
  • 0
FrankM

FrankM

Posted
Posted

First, thanks!

 

I have problems with the image. 

Welcome to ARMBIAN 5.67 stable Debian GNU/Linux 9 (stretch) 4.4.166-rockchip64

1. u-boot in SPI, SSD with Armbian image is on USB3. No Boot, same as with kamils image.

 

2. u-boot in SPI. SSD with Armbian image is on USB2.

  

Warning: a reboot is needed to finish resizing the filesystem  
Please reboot the system as soon as possible

But i have done it several times.

Link to comment
Share on other sites
  • 0
Igor

Igor

Posted
Posted
21 minutes ago, FrankM said:

No Boot, same as with kamils image.


This very first build is based on his work + a few of our addons and fixes. We had odd troubles with booting this thingy from an SD card, as you can read above, and I guess nobody even tried SPI yet.  Now you did (thanks!) and now we know it doesn't work :(

Problems are expected at this stage and a label "testing" will stay on images for some time. 

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to question listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept