How to build for an unsupported board (Pine64 Quartz64)?

[dieselnutjob]

Hi.

 

Firstly, is anyone working on building Armbian for the Quartz64?

If no one else is I would love to give it a try.

What I already have:-

A Quartz64 running slarm64 (or the default manjaro)

Kernel source for above and a dtb file.

A build environment that seems to work (I just built an image for Rock 3a on it).

 

Can anyone give me some ideas on how I clone an existing device in the build environment and start modifying it so that it can build something new?

 

I notice that the legacy kernel that it produced for the Rock 3a is version 4.19.193 which looks good for the Quartz64 as well.  The advantage of this older kernel as used on slarm64 is that the HDMI output works,

 

Any help for a newbie at this would be appreciated.

[Werner]

Example for adding a new board  to existing family (rockchip64 in this case): https://github.com/armbian/build/pull/3138/files

[Igor]

5 hours ago, dieselnutjob said:

Firstly, is anyone working on building Armbian for the Quartz64?

Officially no. Too many hardware is seeking for very low time and expertise.

 

5 hours ago, dieselnutjob said:

A build environment that seems to work (I just built an image for Rock 3a on it).

Example of first start
https://github.com/armbian/build/commit/3c4b69650e9f98edbf7f0a934add1dd19eb14772
Yes, it might looks complicated, but we are working on to improve the procedure. That is generally more useful for us.

 

5 hours ago, dieselnutjob said:

Can anyone give me some ideas on how I clone an existing device in the build environment and start modifying it so that it can build something new?

 

Documentation - start there first:

https://docs.armbian.com/Developer-Guide_Build-Preparation/

https://docs.armbian.com/Process_Contribute/

... and do small steps.

 

5 hours ago, dieselnutjob said:

I notice that the legacy kernel that it produced for the Rock 3a is version 4.19.193 which looks good for the Quartz64 as well.  The advantage of this older kernel as used on slarm64 is that the HDMI output works,

That kernel is shipped with the chip, while path to modern kernel is long, hard and expensive:
https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one

 

5 hours ago, dieselnutjob said:

Any help for a newbie at this would be appreciated.

 

Armbian framework help yes, while for hardware related features - we can't finance hardware vendor business.

[dieselnutjob]

Thanks Igor.  I don't work for Pine64, I just want to use the board for my own project.  I will have a go at seeing how far I can get with this myself.

[dieselnutjob]

I have a question about the RK3566 GPU.  It's a "Mali-G52 2EE Bifrost GPU"

 

According to this page https://wiki.debian.org/PanfrostLima there is a driver from Debian 11, but doesn't that depend on a particular version (and onwards of kernel)?  really I have no idea, the page doesn't say.

 

My thinking is that probably to get Panfrost working on this board I am going to need a newer kernel, however the HDMI output only works with an older 4.19 kernel.  So that means that for now we are stuck.  You can have Panfrost or working HDMI output but not both...

 

Have I misunderstood something?

 

Pine64 seem to suggest that are working on it. I would be okay with doing what I can do for now and wait for them to get HDMI output working on a newer kernel.

 

Anyway there is a high probability that I have gotten this wrong so please anyone correct me.

 

Also can anyone tell me how this would all work if I want to have phosh instead of XFCE?

[Igor]

1 hour ago, dieselnutjob said:

Thanks Igor.  I don't work for Pine64,

And what would that change?  I don't have nothing against Pine64 people. I even had a beer on few occasions.

 

1 hour ago, dieselnutjob said:

 there is a driver from Debian 11

Debian doesn't make low level drivers. Panfrost / Lima is "just" 3D engine.

 

We provide all those drivers in modern kernel (years before Debian), but this chip is AFAIK not supported yet. Or there is no video engine in mainline ... not sure what is the status and I have no interest to know more then this.

 

1 hour ago, dieselnutjob said:

Have I misunderstood something?

Everything  But don't worry. This is quite normal. Instead of asking question from people that can't afford to guide you from huge distance, dig into the documentation. Its plenty of it. Just be prepared for some serious investment into knowledge. If you are prepared. In order to understand and to start asking questions that are useful. For the goal you have. I gave you few hints ... follow them, use search - this forum is a goldmine.

[CryBaby]

I have been following Quartz64_Development as I believe it will also mostly apply to RK3568 support. If I interepret it correctly almost everything needed will be in kernel 5.16 except VOP2 which is necessary for HDMI output. So a headless Armbian is probably feasible.

[dieselnutjob]

When I look at this file https://github.com/armbian/build/blob/master/config/boards/rock-3a.wip it contains this line

BOOTCONFIG="rock-3-a-rk3568_defconfig"

 

and when rock-3a is compiled it says in compilation.log 

== u-boot make rock-3-a-rk3568_defconfig ==

 

I can make a copy of rock-3a.wip to a new file quartz64-model-a.csc and start changing stuff, and it shows up in the menu and compiles (as a sort of rock3a clone).

 

I can't find where this "rock-3-a-rk3568_defconfig" file is in github/armbian so that I can make a new one for the quartz64 with different stuff in it.

 

Can anyone tell me how to make a new defconfig in my fork please?

[Igor]

2 hours ago, dieselnutjob said:

Can anyone tell me how to make a new defconfig in my fork please?

 

https://docs.armbian.com/Developer-Guide_Build-Preparation/ -> https://docs.armbian.com/Developer-Guide_Build-Options/

CREATE_PATCHES="yes"

You need to edit u-boot sources and armbian framework will make you a patch. This patch you add to the patches for future inclusion ...

 

3 hours ago, CryBaby said:

If I interpret it correctly

 

Golden rule - never trust hardware vendors claims regarding software support status  Even all support is promised for the next Linux build and when video part will show something, HW vendor will proclaim "stable" build ... We have completely different view. Mainline Linux is a RAW material, that needs additional attention ...

 

Most popular matured devices from some other time with stable support, but long dead from commercial POW, also regularly bump into troubles - we suppose to take care for its resolving. HW vendors are long gone ...

 

For example RK3399 boards, which are not that old, suspend, most critical notebook / phone function, doesn't work in mainline ... Headless is possible, yes, but those contributors are totally overloaded with securing that old devices works. But we welcome anyone that will try to do something about.

[jeanrhum]

Hi, you can also give a try to Balbes150 images for station m2:

In my opinion, the main problem is the dtb that should be adapted from rock pi3a or station m2, but the image should boot and some basics features (SoC related) may work depending on the kernel version. Other features related to additional hardware (eth,wlan,usb,etc.) may be different and need dts modifications.

[dieselnutjob]

9 hours ago, jeanrhum said:

Hi, you can also give a try to Balbes150 images for station m2:

In my opinion, the main problem is the dtb that should be adapted from rock pi3a or station m2, but the image should boot and some basics features (SoC related) may work depending on the kernel version. Other features related to additional hardware (eth,wlan,usb,etc.) may be different and need dts modifications.

 

yes I have, and these things can be made to work.

However it not what I want to do.

When someone produces an image, then, if open source means open source then some other person, should be able to reproduce that image.

That's why I wrote this guide https://wiki.pine64.org/wiki/Android_SDK_for_RK3566

I spent hours and hours trying to reliably build Android images for the Quartz64 (and I still haven't achieved it), and it really annoyed me that it's so hard to do.

This is one of the reasons that I love LineageOS; clear simple instructions that help ordinary folks like me to compile it themselves.

Images are great for people to use, and I appreciate their efforts, but it is not what I want to achieve. I want to be able to produce and modify images myself, from the source code.

I like what the Armbian project stands for.  My understanding is that it is tools to help non-genius people like me to turn source code into working images.  That's what I want to do.

Modifying someone else's binary image is a start, but it's not my intended destination.

Sorry if that sounds like a rant.  I'm sure that you are trying to help.

 

20 hours ago, Igor said:

 

https://docs.armbian.com/Developer-Guide_Build-Preparation/ -> https://docs.armbian.com/Developer-Guide_Build-Options/

CREATE_PATCHES="yes"

 

 

[quote=https://docs.armbian.com/Developer-Guide_Build-Preparation/#providing-build-configuration]After the first run of compile.sh a new configuration file config-example.conf and symlink config-default.conf will be created. You may edit it to your needs or create different configuration files using it as a template.[/quote]

 

It says CREATE_PATCHES ( yes | no ):

So no in bold means default; right?

I have compiled Rock 3a, and then I look in userpatches/config-example.conf

No mention of CREATE_PATCHES

Also none in compile.sh

 

Therefore my conclusion (please correct me if wrong) is that compiling Rock 3A out of the box is not modifying uboot at all, because CREATE_PATCHES is "off".

 

It is downloading and compiling uboot with a configuration of "rock-3-a-rk3568_defconfig" that uboot already contains (I think),

 

Conclusion: I asked the wrong question

 

I asked how to change the defconf.

 

I should have asked, how does that defconf that's already there, in u-boot actually work.  Where can I find what that option does and what other options there are?

 

When I search everywhere for this string I cannot find it

root@buildarmbian:/home/philip/build# grep -r -i rock-3-a-rk3568_defconfig *
grep: cache/sources/u-boot-rockchip64/stable-4.19-rock3/.git/index: binary file matches
config/boards/quartz64-model-a.csc:BOOTCONFIG="rock-3-a-rk3568_defconfig"
config/boards/rock-3a.wip:BOOTCONFIG="rock-3-a-rk3568_defconfig"
output/debug/compilation.log:   == u-boot make rock-3-a-rk3568_defconfig ==
output/debug/output.log:Config file: rock-3-a-rk3568_defconfig
grep: output/images/Armbian_21.11.0-trunk_Quartz64-model-a_bullseye_legacy_4.19.193.img: binary file matches

 

So I need to figure out what this "rock-3-a-rk3568_defconfig" in the build/config/boards/rock-3a.wip file actually does to uboot and where I can find it in the uboot source code.

 

Maybe there is another option already in the code, and I don't need to modify the code at all, just select the right defconf for my board.  Maybe ....

 

in cache/sources/u-boot-rockchip64/stable-4.19-rock3/README it says

 

Selection of Processor Architecture and Board Type:
---------------------------------------------------

For all supported boards there are ready-to-use default
configurations available; just type "make <board_name>_defconfig".

Example: For a TQM823L module type:

        cd u-boot
        make TQM823L_defconfig

Note: If you're looking for the default configuration file for a board
you're sure used to be there but is now missing, check the file
doc/README.scrapyard for a list of no longer supported boards.

 

I'm getting warmer

[dieselnutjob]

found it

 

cache/sources/u-boot-rockchip64/stable-4.19-rock3/configs/rock-3-a-rk3568_defconfig

 

reading

 

cache/sources/u-boot-rockchip64/stable-4.19-rock3/configs/README.rockchip

[dieselnutjob]

apparently I need to do this:-

 

https://forum.pine64.org/showthread.php?tid=14507

[dieselnutjob]

23 hours ago, dieselnutjob said:

apparently I need to do this:-

 

https://forum.pine64.org/showthread.php?tid=14507

 

 

I am out of my depth.  Patching code that I don't understand with a patch that I don't understand and then converting that it into Armbian build scripts that I don't understand.

 

I know that mara's code works because I can boot his images.

 

I wrote my own board config here https://github.com/dieselnutjob/build/blob/master/config/boards/quartz64-model-a.csc

 

# Rockchip RK3566 quad core 1-8GB SoC GBe eMMC USB3
BOARD_NAME="Quartz64-model-A"
BOARDFAMILY="rk35xx"
BOOTCONFIG="rk3566_quartz64_defconfig"
KERNEL_TARGET="legacy"
FULL_DESKTOP="no"
BOOT_LOGO="desktop"
BOOT_FDT_FILE="rockchip/rk3566-quartz64-a.dtb"
BOOT_SCENARIO="tpl-spl-blob"

 

The BOOT_SCENARIO is a total guess.  The quartz64 can boot from MicroSD card or eMMC module. There is a space for an SPI chip on the board but it isn't populated.  However I think it has more to do with the idbloader.img (TPL/SPL) mode described here http://opensource.rock-chips.com/wiki_Boot_option in my mind

 

This is his rk3566_quartz64_defconfig if I have done it right which would go into build/cache/sources/u-boot-rockchip64/stable-4.19-rock3/configs/

 

Spoiler

CONFIG_ARM=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_SPL_LIBCOMMON_SUPPORT=y
CONFIG_SPL_LIBGENERIC_SUPPORT=y
CONFIG_SYS_MALLOC_F_LEN=0x80000
CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.sh"
CONFIG_ROCKCHIP_RK3568=y
CONFIG_ROCKCHIP_FIT_IMAGE=y
CONFIG_ROCKCHIP_VENDOR_PARTITION=y
CONFIG_ROCKCHIP_FIT_IMAGE_PACK=y
CONFIG_SPL_SERIAL_SUPPORT=y
CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
CONFIG_TARGET_EVB_RK3568=y
CONFIG_SPL_LIBDISK_SUPPORT=y
CONFIG_SPL_NAND_SUPPORT=y
CONFIG_SPL_SPI_FLASH_SUPPORT=y
CONFIG_SPL_SPI_SUPPORT=y
CONFIG_DEFAULT_DEVICE_TREE="rk3566-quartz64"
CONFIG_SMBIOS_PRODUCT_NAME=""
CONFIG_DEBUG_UART=y
CONFIG_FIT=y
CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_FIT_HW_CRYPTO=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_FIT_HW_CRYPTO=y
# CONFIG_SPL_SYS_DCACHE_OFF is not set
CONFIG_BOOTDELAY=0
CONFIG_SYS_CONSOLE_INFO_QUIET=y
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_ANDROID_BOOTLOADER=y
# CONFIG_ANDROID_WRITE_KEYBOX is not set
CONFIG_ANDROID_AVB=y
# CONFIG_ANDROID_KEYMASTER_CA is not set
CONFIG_ANDROID_BOOT_IMAGE_HASH=y
CONFIG_SPL_BOARD_INIT=y
# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
CONFIG_SPL_SEPARATE_BSS=y
CONFIG_SPL_SHA256_SUPPORT=y
CONFIG_SPL_CRYPTO_SUPPORT=y
CONFIG_SPL_HASH_SUPPORT=y
CONFIG_SPL_MMC_WRITE=y
CONFIG_SPL_MTD_SUPPORT=y
CONFIG_SPL_MTD_WRITE=y
CONFIG_SPL_ATF=y
CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
CONFIG_SPL_AB=y
CONFIG_FASTBOOT_BUF_ADDR=0xc00800
CONFIG_FASTBOOT_BUF_SIZE=0x04000000
CONFIG_FASTBOOT_FLASH=y
CONFIG_FASTBOOT_FLASH_MMC_DEV=0
CONFIG_CMD_BOOTZ=y
# CONFIG_CMD_BOOTEFI_HELLO_COMPILE is not set
CONFIG_CMD_DTIMG=y
# CONFIG_CMD_ELF is not set
# CONFIG_CMD_IMI is not set
# CONFIG_CMD_IMLS is not set
# CONFIG_CMD_XIMG is not set
# CONFIG_CMD_LZMADEC is not set
# CONFIG_CMD_UNZIP is not set
# CONFIG_CMD_FLASH is not set
# CONFIG_CMD_FPGA is not set
CONFIG_CMD_GPT=y
# CONFIG_CMD_LOADB is not set
# CONFIG_CMD_LOADS is not set
CONFIG_CMD_BOOT_ANDROID=y
CONFIG_CMD_BOOT_ROCKCHIP=y
CONFIG_CMD_MMC=y
CONFIG_CMD_MTD=y
CONFIG_CMD_NAND=y
CONFIG_CMD_USB=y
CONFIG_CMD_USB_MASS_STORAGE=y
# CONFIG_CMD_ITEST is not set
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_TFTPPUT=y
CONFIG_CMD_TFTP_BOOTM=y
CONFIG_CMD_TFTP_FLASH=y
# CONFIG_CMD_MISC is not set
# CONFIG_CMD_CHARGE_DISPLAY is not set
CONFIG_CMD_MTD_BLK=y
# CONFIG_SPL_DOS_PARTITION is not set
# CONFIG_ISO_PARTITION is not set
CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64
CONFIG_SPL_OF_CONTROL=y
CONFIG_OF_LIVE=y
CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
# CONFIG_NET_TFTP_VARS is not set
CONFIG_REGMAP=y
CONFIG_SPL_REGMAP=y
CONFIG_SYSCON=y
CONFIG_SPL_SYSCON=y
CONFIG_CLK=y
CONFIG_SPL_CLK=y
CONFIG_DM_CRYPTO=y
CONFIG_SPL_DM_CRYPTO=y
CONFIG_ROCKCHIP_CRYPTO_V2=y
CONFIG_SPL_ROCKCHIP_CRYPTO_V2=y
CONFIG_DM_RNG=y
CONFIG_RNG_ROCKCHIP=y
CONFIG_ROCKCHIP_GPIO=y
CONFIG_ROCKCHIP_GPIO_V2=y
CONFIG_SYS_I2C_ROCKCHIP=y
CONFIG_DM_KEY=y
CONFIG_RK8XX_PWRKEY=y
CONFIG_ADC_KEY=y
CONFIG_MISC=y
CONFIG_SPL_MISC=y
CONFIG_ROCKCHIP_OTP=y
CONFIG_SPL_ROCKCHIP_SECURE_OTP_V1=y
CONFIG_MMC_DW=y
CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
CONFIG_MTD=y
CONFIG_MTD_BLK=y
CONFIG_MTD_DEVICE=y
CONFIG_NAND=y
CONFIG_NAND_ROCKCHIP_V9=y
CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y
CONFIG_SYS_NAND_U_BOOT_OFFS=0x8000
CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND=0x10000
CONFIG_MTD_SPI_NAND=y
CONFIG_SPI_FLASH=y
CONFIG_SF_DEFAULT_SPEED=20000000
CONFIG_SPI_FLASH_EON=y
CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_SPI_FLASH_MACRONIX=y
CONFIG_SPI_FLASH_WINBOND=y
CONFIG_SPI_FLASH_XMC=y
CONFIG_SPI_FLASH_MTD=y
CONFIG_DM_ETH=y
CONFIG_DM_ETH_PHY=y
CONFIG_DWC_ETH_QOS=y
CONFIG_GMAC_ROCKCHIP=y
CONFIG_PHY_ROCKCHIP_INNO_USB2=y
CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
CONFIG_PHY_ROCKCHIP_NANENG_EDP=y
CONFIG_PINCTRL=y
CONFIG_SPL_PINCTRL=y
CONFIG_DM_FUEL_GAUGE=y
CONFIG_POWER_FG_RK817=y
CONFIG_IO_DOMAIN=y
CONFIG_ROCKCHIP_IO_DOMAIN=y
CONFIG_DM_PMIC=y
CONFIG_PMIC_RK8XX=y
CONFIG_REGULATOR_PWM=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_REGULATOR_RK8XX=y
CONFIG_DM_CHARGE_DISPLAY=y
CONFIG_CHARGE_ANIMATION=y
CONFIG_PWM_ROCKCHIP=y
CONFIG_RAM=y
CONFIG_SPL_RAM=y
CONFIG_TPL_RAM=y
CONFIG_ROCKCHIP_SDRAM_COMMON=y
CONFIG_ROCKCHIP_TPL_INIT_DRAM_TYPE=0
CONFIG_DM_RESET=y
CONFIG_SPL_DM_RESET=y
CONFIG_SPL_RESET_ROCKCHIP=y
CONFIG_BAUDRATE=1500000
CONFIG_DEBUG_UART_BASE=0xFE660000
CONFIG_DEBUG_UART_CLOCK=24000000
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_ROCKCHIP_SFC=y
CONFIG_SYSRESET=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_DWC3=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_GENERIC=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_GENERIC=y
CONFIG_USB_DWC3=y
CONFIG_USB_DWC3_GADGET=y
CONFIG_USB_DWC3_GENERIC=y
CONFIG_USB_STORAGE=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_MANUFACTURER="Rockchip"
CONFIG_USB_GADGET_VENDOR_NUM=0x2207
CONFIG_USB_GADGET_PRODUCT_NUM=0x350a
CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_DM_VIDEO=y
CONFIG_DISPLAY=y
CONFIG_DRM_ROCKCHIP=y
CONFIG_DRM_ROCKCHIP_DW_HDMI=y
CONFIG_DRM_ROCKCHIP_INNO_MIPI_PHY=y
CONFIG_DRM_ROCKCHIP_INNO_VIDEO_COMBO_PHY=y
CONFIG_DRM_ROCKCHIP_DW_MIPI_DSI=y
CONFIG_DRM_ROCKCHIP_ANALOGIX_DP=y
CONFIG_DRM_ROCKCHIP_LVDS=y
CONFIG_LCD=y
CONFIG_USE_TINY_PRINTF=y
CONFIG_SPL_TINY_MEMSET=y
CONFIG_RSA=y
CONFIG_SPL_RSA=y
CONFIG_RSA_N_SIZE=0x200
CONFIG_RSA_E_SIZE=0x10
CONFIG_RSA_C_SIZE=0x20
CONFIG_SHA512=y
CONFIG_LZ4=y
CONFIG_SPL_GZIP=y
CONFIG_ERRNO_STR=y
CONFIG_AVB_LIBAVB=y
CONFIG_AVB_LIBAVB_AB=y
CONFIG_AVB_LIBAVB_ATX=y
CONFIG_AVB_LIBAVB_USER=y
CONFIG_RK_AVB_LIBAVB_USER=y
CONFIG_OPTEE_CLIENT=y
CONFIG_OPTEE_V2=y

 

Could someone who actually knows what they are doing have a look and give me some ideas please?

 

Edited November 17, 2021 by TRS-80
put long output inside spoiler

[Igor]

9 hours ago, dieselnutjob said:

I am out of my depth.

I am dealing around u-boot for past 8 years, with Linux 30+ years, with Unix a little more than that, but I can't answer your questions just like that. tl;dr; I didn't expect any question in matter of hours, but weeks / months. Things you are up to, require a lot of research - for anyone. Slow down.

 

9 hours ago, dieselnutjob said:

give me some ideas please?

 

If you want to learn something without hitting the wall hard, get off from the board that hasn't been hacked from proprietary junk (stock Rockchip firmware) to human understandable code. 

 

I barely find time for people that help project: https://forum.armbian.com/staffapplications/

[jeanrhum]

I suppose that most images generated by Balbes150 are from his github repository: https://github.com/150balbes/build

So you may be able to access sources and build an image by yourself.

[dieselnutjob]

2 hours ago, jeanrhum said:

I suppose that most images generated by Balbes150 are from his github repository: https://github.com/150balbes/build

So you may be able to access sources and build an image by yourself.

 

I don't see a P2 or M2 in there https://github.com/150balbes/build/tree/armbian-tv/config/boards 

Maybe I should try and reach out to Balbes150.

[dieselnutjob]

2 hours ago, Igor said:

If you want to learn something without hitting the wall hard, get off from the board that hasn't been hacked from proprietary junk (stock Rockchip firmware) to human understandable code.

 

Which SoC do you suggest as being the most open source friendly?  and I mean ones that are available to smaller / multiple board suppliers so not the Broadcom ones that appear to be only available to the Raspberry Pi Foundation.

[Igor]

22 minutes ago, dieselnutjob said:

most open source friendly? 

https://www.armbian.com/download/?tx_soc=h5

https://www.armbian.com/download/?tx_soc=h3

old & slow, but still good for learning purposes: https://www.armbian.com/download/?tx_soc=a20

Perhaps some of those:
https://www.armbian.com/download/?tx_soc=rk3399 (oldest of them like Nanopi M4)

[TRS-80]

On 11/16/2021 at 5:43 PM, dieselnutjob said:

yes I have, and these things can be made to work.

However it not what I want to do.

When someone produces an image, then, if open source means open source then some other person, should be able to reproduce that image.

That's why I wrote this guide https://wiki.pine64.org/wiki/Android_SDK_for_RK3566

I spent hours and hours trying to reliably build Android images for the Quartz64 (and I still haven't achieved it), and it really annoyed me that it's so hard to do.

This is one of the reasons that I love LineageOS; clear simple instructions that help ordinary folks like me to compile it themselves.

Images are great for people to use, and I appreciate their efforts, but it is not what I want to achieve. I want to be able to produce and modify images myself, from the source code.

I like what the Armbian project stands for.  My understanding is that it is tools to help non-genius people like me to turn source code into working images.  That's what I want to do.

Modifying someone else's binary image is a start, but it's not my intended destination.

 

Well, your heart is in the right place. 

 

I have worked a little bit on the docs, but I/we welcome suggestions.  Especially from people new to the project.  What you might not realize is that it's hard for people like Igor, et al, who have so much experience, to remember what it was like in the beginning.  So please do continue making some notes about things you learned, resources you found, misconceptions you had, and we can try and incorporate them into docs/wiki at some point.

 

What you set out to do here is not trivial task, this SoC is not even supported in mainline Linux yet, it is basically almost brand new chip.  I was very excited about RK3399 for instance but that took literally years to finally get to the usable state it is in today.  And I suspect same will be the case with this RK3566.

[dieselnutjob]

So where I started with all this.

I originally took 150balbes binary image for the Station M2 and discovered that by making some pretty minor config changes I could get it to boot on my quartz64.

Now I have found 150balbes source code, and I can compile it from source ( it's here https://github.com/150balbes/build/tree/station-x2 ).

I think that I found his "secret sauce".  I think that maybe it's here https://github.com/150balbes/build/blob/station-x2/config/sources/families/rockchip64.conf

what it contains is this

source "${BASH_SOURCE%/*}/include/rockchip64_common.inc"

case $BRANCH in

	legacy)
		KERNELDIR='linux-rockchip64'

		if [[ $BOARD == station-p2 || $BOARD == station-m2 ]]; then
			BOOTSOURCE='https://github.com/150balbes/u-boot-rk'
			BOOTBRANCH='branch:rk356x'
			BOOTPATCHDIR="u-boot-station-p2"

			KERNELSOURCE='https://github.com/150balbes/rockchip-kernel'
			KERNELBRANCH='branch:rk35xx'
			KERNELPATCHDIR='station-p2-'$BRANCH
			LINUXCONFIG='linux-station-p2-'$BRANCH
			LINUXFAMILY=station-p2
		else
			KERNELSOURCE='https://github.com/ayufan-rock64/linux-kernel'
			KERNELBRANCH='tag:4.4.202-1237-rockchip-ayufan'
			KERNELPATCHDIR='rockchip64-'$BRANCH
		fi

	;;

esac

prepare_boot_configuration

 

So, for a station-m2 there is a dependancy on his own u-boot-rk and rockchip-kernel repos.

 

Can that ever be merged back into something hosted by Armbian ?

 

And what if I further modify it to support the quartz64 ?  Then it's a mod of a mod so even harder to merge back in.

 

Presumably what I should do is fork his repos into my own repo and then do an if $BOARD == quartz64-a then blah blah my repo ?

 

Sorry; I'm new to git.

 

This seems like a mess, maybe it's just me.

 

What's the "right" way to do this?

[jeanrhum]

If the main difference with original armbian is mainly relating to this code, I would prefer to fork armbian and apply similar modifications afterwards. Then, changing u-boot and kernel sources are mainly here to use specific patches, but it is sometimes difficult to understand them and combine them so that it works.

 

[dieselnutjob]

I suppose that this is the problem with open source.

You can end up with a fork of a fork of a fork and then it's very difficult to merge it back into the original code.

In no way do I mean any of this as a criticism of 150balbes.

I don't think that any of us get paid for this and probably we all want something that works, and forking the nearest to what works rather than the original project is of course the easiest way to achieve that.

[dieselnutjob]

The other point is, if you look at the original Armbian code at https://github.com/armbian/build/blob/master/config/sources/families/rockchip64.conf

source "${BASH_SOURCE%/*}/include/rockchip64_common.inc"

case $BRANCH in

	legacy)
		KERNELSOURCE='https://github.com/ayufan-rock64/linux-kernel'
		KERNELBRANCH='tag:4.4.202-1237-rockchip-ayufan'
		KERNELDIR='linux-rockchip64'
		KERNELPATCHDIR='rockchip64-'$BRANCH
	;;

esac

prepare_boot_configuration

 

that in itself depends on the ayufan-rock64 repo.

So if it doesn't actually work on a specific board then what are 150balbes or myself supposed to do about it?

Who's to say that the ayufan-rock64 repo is any more legitimate than 150balbes?

This is, I think, entirely the fault of Rockchip for not providing upto date working code for the RK3566, and by working I mean with an HDMI port that actually works.

[dieselnutjob]

looking at https://github.com/150balbes/build/blob/station-x2/config/sources/families/rockchip64.conf

 

if [[ $BOARD == station-p2 || $BOARD == station-m2 ]]; then
			BOOTSOURCE='https://github.com/150balbes/u-boot-rk'
			BOOTBRANCH='branch:rk356x'
			BOOTPATCHDIR="u-boot-station-p2"

			KERNELSOURCE='https://github.com/150balbes/rockchip-kernel'
			KERNELBRANCH='branch:rk35xx'
			KERNELPATCHDIR='station-p2-'$BRANCH
			LINUXCONFIG='linux-station-p2-'$BRANCH
			LINUXFAMILY=station-p2
		else
			KERNELSOURCE='https://github.com/ayufan-rock64/linux-kernel'
			KERNELBRANCH='tag:4.4.202-1237-rockchip-ayufan'
			KERNELPATCHDIR='rockchip64-'$BRANCH
		fi

 

can anyone tell me where this "station-m2" board name comes from?

 

looking at this file https://github.com/150balbes/build/blob/station-x2/config/boards/station-m2.wip

# Rockchip RK3566
BOARD_NAME="Station M2"
BOARDFAMILY="rockchip64"
BOOTCONFIG="firefly-rk3568_defconfig"
KERNEL_TARGET="legacy,current,edge"
FULL_DESKTOP="yes"
BOOT_LOGO="desktop"
BOOT_FDT_FILE="rockchip/rk3566-firefly-roc-pc.dtb"
SRC_EXTLINUX="yes"
SRC_CMDLINE="console=uart8250,mmio32,0xfe660000 console=tty0"
ASOUND_STATE="asound.state.station-m2"
IMAGE_PARTITION_TABLE="gpt"

 

the string "station-m2" only appears in the filename "station-m2.wip".  Is it the filename itself that gets converted into $BOARD or does it get populated some other way?

[jeanrhum]

It seems that 5.16 kernel has hdmi working:

 

[dieselnutjob]

3 hours ago, jeanrhum said:

It seems that 5.16 kernel has hdmi working:

 

 

I just tried the Station-m2 bullseye image on my Quartz64-A

 

It wouldn't boot past initram with an eMMC module as it couldn't find its root partition.

 

I boots on microSD card

 

The HDMI output doesn't display on th Quartz64

 

To try it you need to dd the image onto a microSD card, then mount it in linux and modify the /boot/extlinux/extlinux.conf file like this:-

LABEL Armbian
  LINUX /boot/Image
  INITRD /boot/uInitrd
  FDT /boot/dtb/rockchip/rk3566-quartz64-a.dtb
  APPEND root=UUID=563b30fb-fd81-42bf-92bf-757c1b1cd11f console=uart8250,mmio32,0xfe660000 console=tty1 console=ttyFIQ0,1500000n8 rootflags=data=writeback rw no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 bootsplash.bootfile=bootsplash.armbian

 

[dieselnutjob]

thanks to mara on the pine64 forum I can now compile u-boot for the Quartz64 from source, tested it and it works.

The code is here https://github.com/dieselnutjob/u-boot.git

Instructions are here https://github.com/dieselnutjob/u-boot/blob/quartz64-a/README

 

I also have the source code for his kernel for the board.

I have put that here https://github.com/dieselnutjob/kernel-rk3566.git but I haven't figured out how to compile it yet.

 

[dieselnutjob]

Time for an update.

I can compile u-boot for the quartz64.  Instructions are here https://github.com/dieselnutjob/u-boot

I can modify armbian build to download that same u-boot code and compile it

That code is here https://github.com/dieselnutjob/build

however when I run compile.sh in build I get this error

CFGCHK u-boot.cfg
Unsupported u-boot processing configuration!

 

on investigation I found that build/cache/sources/u-boot/quartz64-a/u-boot.cfg is not the same as the u-boot.cfg if I compile u-boot directly from my own source outside of the armbian build scripts.

 

I don't yet understand why.

[dieselnutjob]

aha maybe it's something to do with these lines

[ o.k. ] Cleaning [ u-boot/quartz64-a ]
[ o.k. ] Compiling u-boot [ 2017.09 ]
[ o.k. ] Compiler version [ aarch64-none-linux-gnu-gcc 9.2.1 ]
[ .... ] Checking out to clean sources 
[ o.k. ] Cleaning [ u-boot/quartz64-a ]
[ o.k. ] Started patching process for [ u-boot station-p2-quartz64-a-legacy ]
[ o.k. ] Looking for user patches in [ userpatches/u-boot/u-boot-station-p2 ]

 

I need to remove some of 150balbes userpatches I guess