Jump to content

[Rock64 debian] Building a replica of current testing image


Recommended Posts

Hello,

 

I have been able to run the rock64 testing image posted in https://www.armbian.com/rock64/

 

I want to customize this image through userpatches/customize-image.sh, as I have done in the past with the odroid HC1. The plan is to create more SD card images with NextCloudPi

 

As a first step, I want to replicate that testing image, that works for me. Following Igor's advice in this post, I tried with the following command

 

./compile.sh docker \ 
  BOARD=rock64\
  BRANCH=default\
  KERNEL_ONLY=no\
  KERNEL_CONFIGURE=no\
  RELEASE=stretch\
  BUILD_DESKTOP=no\
  EXPERT=yes

 

I was asked a few questions regarding kernel configuration ( see attached file ). Seems like defconf doesn't cover all options. I tried the defaults and the resulting image doesn't boot.

 

What am I missing in order to replicate said working test image?

 

Thanks!

 

 

rockbuild.txt

Link to comment
Share on other sites

You need yet another switch LIB_TAG="development" / untested under Docker to switch into the development branch. I am not sure master is updated for Rock64.

Link to comment
Share on other sites

27 minutes ago, nachoparker said:

 

I was asked a few questions regarding kernel configuration ( see attached file ). Seems like defconf doesn't cover all options.

Happens when the kernel which we use gets updated and adjustments from a dev weren't made to make sure this changes work for building a new image (or in this case only in the development branch of our buildscript). A nice example what's done 'behind the scenes' and how much efforts it needs to keep the project running. :)  (keep in mind, this has to be done for ~30 different kernels)

 

38 minutes ago, nachoparker said:

I tried the defaults and the resulting image doesn't boot.

If you dive into development, I strongly suggest that you have a USB-UART console at hand to provide a boot-log. The image doesn't boot is not enough information to help you solving the issues you have. 

 

22 minutes ago, Igor said:

I am not sure master is updated for Rock64.

would it make sense to check out with specific tags for the master branch to make sure 'everything works'? I'm a complete git noob and not sure if tags are used by the repos we use. :) Seems that RK uses tags, this might slow down the 'update speed' a little bit, but would avoid such issues (e.g. keep development branch at master and our master at the last tag provided by the kerneldeveloper - for bsp kernels). 

Link to comment
Share on other sites

Thanks again for your answers.

 

18 hours ago, Igor said:

You need yet another switch LIB_TAG="development" / untested under Docker to switch into the development branch. I am not sure master is updated for Rock64.

 

Unfortunatedly, this wasn't enough for me. I tried to rebuild with this command

 

./compile.sh docker \
  BOARD=rock64\
  BRANCH=default\
  KERNEL_ONLY=no\
  KERNEL_CONFIGURE=no\
  RELEASE=stretch\
  BUILD_DESKTOP=no\
  EXPERT=yes \
  LIB_TAG="development"\
  USE_CCACHE=yes

 

, and again I got asked for input because of incomplete kernel configuration. Hitting the defaults, the resulting image doesn't boot. U-boot doesn't find the kernel, and tries to get it through TFTP. See attachment for UART output.

 

I don't want to waste your time, and I understand if a development image doesn't boot. I would just like to know if there is a way to replicate an image that I already know that works using the building system. The image uploaded to https://www.armbian.com/rock64/ must have some kind of tagging or commit that can be somehow passed on to the build script to replicate that exact image, right?

 

Anything else I am missing?

 

Thanks!

rock.txt

Link to comment
Share on other sites

9 hours ago, nachoparker said:

https://www.armbian.com/rock64/ must have some kind of tagging or commit that can be somehow passed on to the build script to replicate that exact image, right?

No, even if we tag the build script we are almost always using branches and not tags for upstream sources (kernel, u-boot, ATF), so it is possible that things would get changed and broken over time.

 

9 hours ago, nachoparker said:

Unfortunatedly, this wasn't enough for me. I tried to rebuild with this command

 LIB_TAG should be changed in the configuration file, it cannot be set via command line.

Link to comment
Share on other sites

Hi,

 

It seems that we have a stable version now, congratulations for the hard work! -> https://www.armbian.com/rock64/

 

Still, I couldn't build it. I pulled the latest master and it still shows in the menu as WIP. When I build it with

 

./compile.sh docker \
  BOARD=rock64\
  BRANCH=default\
  KERNEL_ONLY=no\
  KERNEL_CONFIGURE=no\
  RELEASE=stretch\
  BUILD_DESKTOP=no\
  USE_CCACHE=yes

 

It gets stuck at

 

U-Boot 2017.09-armbian (Apr 12 2018 - 18:09:32 +0000)

Model: Pine64 Rock64
DRAM:  DDR version 1.06 20170424
In
LPDDR3
786MHz
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=2048MB
ddrconfig:6
OUT
Boot1 Release Time: 2017-05-18, version: 2.43
ChipType = 0x11, 130
emmc reinit
emmc reinit
SdmmcInit=2 20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=7420MB
FwPartOffset=2000 , 0
StorageInit ok = 48550
Raw SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit ret = 0, SecureMode = 0
LoadTrustBL
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0xa4d10
RunBL31 0x10000
NOTICE:  BL31: v1.3(debug):f947c7e
NOTICE:  BL31: Built : 12:22:09, Mar 28 2018
NOTICE:  BL31:Rockchip release version: v1.3
INFO:    ARM GICv2 driver initialized
INFO:    Using rkfiq sec cpu_context!
INFO:    boot cpu mask: 1
INFO:    plat_rockchip_pmu_init: pd status 0xe
INFO:    BL31: Initializing runtime services
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2017.09-armbian (Apr 12 2018 - 18:09:32 +0000)

Model: Pine64 Rock64
DRAM:

 

If I add

 

EXPERT=yes \
LIB_TAG="development"\

 

some patches fail

 

[ warn ] * [l][c] 04-patch-4.4.112-113.patch [ failed ]
[ warn ] * [l][c] 04-patch-4.4.113-114.patch [ failed ]
[ warn ] * [l][c] 04-patch-4.4.114-115.patch [ failed ]

 

And the kernel configuration is incomplete

 

Debug PINCTRL calls (DEBUG_PINCTRL) [N/y/?] n
AMD GPIO pin control (PINCTRL_AMD) [N/y/?] n
One-register-per-pin type device tree based pinctrl driver (PINCTRL_SINGLE) [N/m/y/?] n

 

Anything I am missing? should I wait a little bit longer?

 

Thanks

 

Link to comment
Share on other sites

On 4/13/2018 at 6:25 PM, zador.blood.stained said:

LIB_TAG should be changed in the configuration file, it cannot be set via command line.

 

What configuration file are we talking about? I keep having the same issue with the command

 

./compile.sh docker \
  BOARD=rock64\
  BRANCH=default\
  KERNEL_ONLY=no\
  KERNEL_CONFIGURE=no\
  RELEASE=stretch\
  BUILD_DESKTOP=no\
  EXPERT=yes \
 LIB_TAG="development"\
  USE_CCACHE=yes\

 

Probably not detecting the LIB_TAG parameter. If it's easier to wait a little bit I can wait.

 

Thanks!

Link to comment
Share on other sites

On 5/8/2018 at 5:30 PM, nachoparker said:

What configuration file are we talking about?

config-default.conf 

 

which should look like the following (not the whole file):

...
CREATE_PATCHES="yes"                    # wait that you make changes to uboot a$
BUILD_ALL="no"                          # cycle through available boards and ma$
                                        # set KERNEL_ONLY to "yes" or "no" to b$

BSPFREEZE=""                            # freeze armbian packages (u-boot, kern$
INSTALL_HEADERS=""                      # install kernel headers package
LIB_TAG="development"

 

But I've never used it with docker.. 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines