Bekim Lutolli Posted September 10, 2018 Posted September 10, 2018 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
Igor Posted September 10, 2018 Posted September 10, 2018 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
martinayotte Posted September 22, 2018 Posted September 22, 2018 @Igor , did you got chance to dig the issue ? @pfeerick , @ayufan , any idea ?
Igor Posted September 22, 2018 Posted September 22, 2018 3 hours ago, martinayotte said: did you got chance to dig the issue ? No, I haven't got back to this problem yet. Not sure when I will be able.
martinayotte Posted September 22, 2018 Posted September 22, 2018 OK ! ... just too bad ... I've tried to dig it myself, with your above uboot_custom_postprocess(), as well as the one from NanoPCT4, but I always have a U-Boot which freeze after DDR init, without any prompt. I don't have much clues ... Hoping @ayufan will help us soon !
martinayotte Posted September 24, 2018 Posted September 24, 2018 In the mean time, I've took a copy of the u-boot of my previous 4.4.132 and push it to newly 4.18.0-rc8. At least, this way, I can troubleshoot DT features for future RockPro64 images ... Current status : eMMC isn't working yet, neither than WiFi ...
martinayotte Posted October 21, 2018 Posted October 21, 2018 On 9/24/2018 at 9:09 AM, martinayotte said: Current status : eMMC isn't working yet, neither than WiFi ... During past weeks, I've resolved issues with eMMC and WiFi, but still not resolved the U-Boot issue ...
chwe Posted October 21, 2018 Posted October 21, 2018 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?
martinayotte Posted October 22, 2018 Posted October 22, 2018 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 ...
chwe Posted October 22, 2018 Posted October 22, 2018 @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?
martinayotte Posted October 22, 2018 Posted October 22, 2018 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 ...
TonyMac32 Posted November 2, 2018 Posted November 2, 2018 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... ) 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.
TonyMac32 Posted November 2, 2018 Posted November 2, 2018 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
martinayotte Posted November 2, 2018 Posted November 2, 2018 7 hours ago, TonyMac32 said: I'll try it with mainline u-boot tomorrow Keep us posted, if you found new recipe, I will be glad to try it out ...
TonyMac32 Posted November 2, 2018 Posted November 2, 2018 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)
chwe Posted November 2, 2018 Posted November 2, 2018 15 hours ago, TonyMac32 said: Channel 0: LPDDR4,50MHz really? 50MHz? sounds fishy.. 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
TonyMac32 Posted November 2, 2018 Posted November 2, 2018 14 minutes ago, chwe said: really? 50MHz? sounds fishy.. 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.
chwe Posted November 2, 2018 Posted November 2, 2018 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.. Similar issues with my H96max a like TV-box board.. well, gonna be a mess to sort out whitch bits are missing.
giminni Posted November 25, 2018 Posted November 25, 2018 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!
giminni Posted November 28, 2018 Posted November 28, 2018 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?
martinayotte Posted November 28, 2018 Posted November 28, 2018 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 ...
giminni Posted November 29, 2018 Posted November 29, 2018 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)?
martinayotte Posted November 29, 2018 Posted November 29, 2018 6 hours ago, giminni said: Hmm, strange why not try boot flow 2 (SPL/TPL)? I've tried in recent days, but still without success ... Once we figure out, we will probably discover that it is a stupid glitch ...
martinayotte Posted December 2, 2018 Posted December 2, 2018 On 11/29/2018 at 1:46 AM, giminni said: Hmm, strange why not try boot flow 2 (SPL/TPL)? I think I got it working ... But doing it manually, not within Armbian build scripts ... I will check if I can integrate that into them ... 3
giminni Posted December 2, 2018 Posted December 2, 2018 6 hours ago, martinayotte said: I think I got it working ... But doing it manually, not within Armbian build scripts ... Great, can you tell me what you have done?
TonyMac32 Posted December 3, 2018 Posted December 3, 2018 @martinayotte I'll take another round with it as well if you provide examples. @giminni The issue here is that we have a small pile of rk3399 boards that boot just fine using "flow 1". Even if we get "flow 2" working, the question as to why it has to be different and clutter up our build system remains.
martinayotte Posted December 3, 2018 Posted December 3, 2018 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
Igor Posted December 3, 2018 Posted December 3, 2018 1 hour ago, martinayotte said: EDIT : Here is the commit https://github.com/armbian/build/commit/c3e46a5d863ebc4d00d666b3a19eed00e3d0c17d ooo, It's alive Will add images ASAP. 3
martinayotte Posted December 3, 2018 Posted December 3, 2018 1 hour ago, Igor said: ooo, It's alive Will add images ASAP. Yes ! It is also bringing some "flow #2" expertise for other RK3399 board in case we get issues with "flow #1" ... Anxiously waiting for my OrangePi-RK3399 to arrive !
FrankM Posted December 4, 2018 Posted December 4, 2018 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.
Recommended Posts