add rock3-c target

[henkwiedig]

This adds Radxa Rock-3 C support.

HDMI works fine.
Currently working on getting the DSI displays working.
We need a way to toggle this.
Manual boot activates the display already.

setenv bootargs quiet splash init=/init root=PARTLABEL=rootfs ro rootwait
mmc dev 1
load mmc 1:1 0x03000000 /boot/Image
load mmc 1:1 0x06000000 /boot/rockchip/rk3566-rock-3c-aic8800ds2.dtb
load mmc 1:1 0x07000000 /boot/rockchip/overlays/rock-3c-radxa-display-8hd.dtb
fdt addr 0x06000000
fdt resize 8192
fdt apply 0x07000000
booti 0x03000000 - 0x06000000

As extlinux.conf is fixed in squashfs we need to somehow overwrite it.

[henkwiedig]

Added the following changes:

• Uboot now tries to load a custom environment from mmc 0:2 and mmc 1:2 to support emmc and sd card boots
  if found, it runs my_bootcmd otherwise it defaults to the previous boot flow
• gsmenu patch and tooling to configure rock3-c supported displays
• adjusted gpio pins

@zhouruixi
what do you think about the custom boot soluion. tried uboot default emmc and ext4 environment loading but none worked for we when considering emmc and sd card booting. despite documentation suggests otherwise.
It only worked for me when specifying deticated mmc devices.

[zhouruixi]

what do you think about the custom boot soluion.

I'm not very familiar with U-Boot, but I have a few thoughts:

• Which is more convenient and easier to maintain, extlinux or ubootcmd?

• I believe the optimal boot configuration file reading order should be: SD DVR partition (fat32) > SD overlay partition (ext4) > SD root partition (squashfs) > emmc DVR partition > emmc overlay partition > emmc root partition. The boot configuration file in the DVR (extlinux.conf or ubootcmd.txt) is user-controlled and has the highest priority. The boot configuration file in the overlay is controlled by pp_rk. The boot configuration file in squashfs uses the default settings and has the lowest priority.

• Now that you are importing the environment from the ext4 overlay partition, what about enabling the U-Boot environment and saving the boot command in it?

---

gsmenu patch and tooling to configure rock3-c supported displays

• Regarding gsmenu, is it necessary to include all configurable items? Obviously, not all boards need to display device switching functionality. Adding related support using pathch would undoubtedly increase maintenance costs significantly. I believe gsmenu should be

  • kept concise, providing only the most frequently used settings.
  • Or non-universal functions could be integrated into gsmenu, but the display of which options is controlled by a configuration file.
  • Or the gsmenu interface be drawn based on the configuration file description.

• gsmenu.sh is becoming increasingly complex and fragmented. Could it be split into two files: one containing universal content for any system (Debian, buildroot, etc.) (gsmenu.sh), and the other containing proprietary content (gsmenu_ext.sh)? The pp_rk repository could primarily maintain the universal portion, while the proprietary portion would contain the commands needed by gsmenu, with gsmenu_ext.sh maintained by each GS edition.

(Please point out any unclear parts in this machine translation.)

[zhouruixi]

I try set CONFIG_BOOTSTD_FULL=y in uboot_bsp_defconfig‎, But can not boot anymore. Can you help to find the reasons? @henkwiedig

=> bootflow scan
** Cannot find directory. **
File not found.
File not found.
File not found.
File not found.
** Cannot find directory. **
Card did not respond to voltage select! : -110
scanning bus for devices...
No ethernet found.
No ethernet found.

[henkwiedig]

• I think i like the extlinux more but i did not find a way to load it the way we need it here

• the boot order you describe is feature creeping to me. we just need a way to add the overlay not a complex boot logic no one will ever use

• what do you mean by "enabling the U-Boot environment" ? a uboot env partition ?
  by loading custom uboot.txt we have the same way of control over uboot environment as with dedicated uboot partitons
  to me both are technically equal solutions while the txt file is easyer to maintain imho.
  also we don't need to re-write init/sysupdate/firstboot toolings so we can keep them just as in the other images and only enable this env loading on specific boards.
  The problem with useing CONFIG_ENV_IS_IN_MMC or CONFIG_ENV_IS_IN_EXT4 is that the require to have a fixed mmc dev and partiton set.
  Which is not what we need. we just need an environment overwrite

• removed the pixelpilot patch and created native connector switching in UI additions PixelPilot_rk#107

• i agree that gsmenu.sh quite a long script and could be organized better but to me that's a tpoic for antoher pr

• also tried the CONFIG_BOOTSTD_FULL=y option, manually running bootflow scan -lb boots the first availabe flow
  problem with all this default mechanisms is that pathes are relative to the booted environment.
  when loading extlinux from the overlay it will also need kernel and dto to be loaded from there.

• last option would be to use a writeable boot partition

[zhouruixi]

I think i like the extlinux more but i did not find a way to load it the way we need it here

also tried the CONFIG_BOOTSTD_FULL=y option, manually running bootflow scan -lb boots the first availabe flow
problem with all this default mechanisms is that pathes are relative to the booted environment.
when loading extlinux from the overlay it will also need kernel and dto to be loaded from there.

You are right, I have tested sysboot mmc 1:2 any ${loadaddr} /root/boot/extlinux/extlinux.conf and bootflow scan -lb mmc1:2, u-boot treats the partition containing extlinux.conf as bootdev and loads the kernel and dtb from it, then failed to load.

the boot order you describe is feature creeping

My main concern is that user modifications to uboot.txt might conflict with the operations performed by pp_rk, so use a top level uboot.txt in DVR partition. If not, pp_rk requires more code logic to ensure it can correctly identify and process user-modified uboot.txt and its settings.

For example, if a user needs to enable a PWM, they modify uboot.txt and add an extra dtbo, but when they set the gs system connector to HDMI, their changes will be deleted.

        if [ "$5" = "HDMI" ]
        then
            rm -f /boot/uboot.txt
        else
            cp /boot/uboot.txt.disabled /boot/uboot.txt

what do you mean by "enabling the U-Boot environment" ?

I mean CONFIG_ENV_IS_IN_MMC. yes, an environment overwrite is better.

last option would be to use a writeable boot partition

This is indeed a common practice, but it's not entirely read-only, maybe that's not what we want at the moment.

[zhouruixi]

How about make uboot.txt environment overwrite as a general feature, not only for rock3c. And add a DTBO settings menu to gsmenu.

• If disabled dtbo in gsmenu then delete uboot.txt.
• If enabled dtbo in gsmenu, traverse /boot/rockchip to obtain available DTBO files and present them to the user as checkboxes. DTBOs already enabled in uboot.txt will be automatically selected. The user can then choose which DTBOs to enable, and the value of fdtfile= in uboot.txt will be set according to the user's selection.

---

overlay configfs is added since b21681b. Which is runtime interface to using configfs for generic device tree overlay usage. With it its possible to use device tree overlays without having to use a per-platform overlay manager. I have tested it is working to enable a uart when OS is running.

Perhaps the required DTBO can be loaded after the kernel starts using an init hook. Could you test what happens when switch the connector from HDMI to MIPI DSI after the kernel booted? @henkwiedig

Documentation/devicetree/configfs-overlays.txt

Howto use the configfs overlay interface.

A device-tree configfs entry is created in /config/device-tree/overlays
and and it is manipulated using standard file system I/O.
Note that this is a debug level interface, for use by developers and
not necessarily something accessed by normal users due to the
security implications of having direct access to the kernel's device tree.

* To create an overlay you mkdir the directory:

	# mkdir /config/device-tree/overlays/foo

* Either you echo the overlay firmware file to the path property file.

	# echo foo.dtbo >/config/device-tree/overlays/foo/path

* Or you cat the contents of the overlay to the dtbo file

	# cat foo.dtbo >/config/device-tree/overlays/foo/dtbo

The overlay file will be applied, and devices will be created/destroyed
as required.

To remove it simply rmdir the directory.

	# rmdir /config/device-tree/overlays/foo

The rationalle of the dual interface (firmware & direct copy) is that each is
better suited to different use patterns. The firmware interface is what's
intended to be used by hardware managers in the kernel, while the copy interface
make sense for developers (since it avoids problems with namespaces).

[zhouruixi]

This pull request contains too many features. I suggest splitting it into several smaller pull requests and merging them one by one.

1. Bump pp_rk and support actions
2. Add Rock 3C support
3. Patch uboot to support loading environment from ext4
4. Add connector or dtbo selector