BigTreeTech CB2/Pi2 config

[JohnTheCoolingFan]

Description

Added patches and config for BigTreeTech CB2/Pi2

GitHub issue reference:
Jira reference number AR-2332

How Has This Been Tested?

Build and load on BTT Pi 2, test peripherals and see how it runs for 5 minutes

• current branch works fine, using BigTreeTech u-boot for cb2: https://github.com/bigtreetech/u-boot/tree/stable-4.19-cb2
• edge is using mainline u-boot, having problems with the board freezing at about 2 minutes 50 seconds of uptime

Checklist:

Please delete options that are not relevant.

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[ColorfulRhino]

Not sure which board you used as template for the board config, but you don't need most of this stuff. Try using this as an example:

https://github.com/armbian/build/blob/main/config/boards/nanopi-r5c.csc (minus the asound and extlinux line, use BOOTBRANCH="tag:v2024.07-rc5" and BOOTCONFIG="generic-rk3568_defconfig" it works well for rk3568/rk3566)

Also, you have put your patches into rockchip instead of rockchip64 😉

And to prevent duplication, you could use a symlink for the dts file to point from one to the other if they're exactly the same, so you only have one dts and the other one is just a symlink (example: https://github.com/armbian/build/tree/main/patch/kernel/rockchip-rk3588-collabora/dt)

[rpardini]

@JohnTheCoolingFan please pick armsurvivors@779b4ee -- you told me the other day I could drop it, but you seem to have forgotten?

@ColorfulRhino that addresses most of your comments, I think?

[JohnTheCoolingFan]

@JohnTheCoolingFan please pick armsurvivors@779b4ee -- you told me the other day I could drop it, but you seem to have forgotten?

@ColorfulRhino that addresses most of your comments, I think?

I did pick it, just didn't push onto a remote branch and it's not used in this branch. This is subject to change during the development of the PR. Pushed it to btt-cb2-rpardini. I have a number of branches for btt cb2 and cb1 and was organizing them yesterday, deleting unneeded ones. Will have to reevaluate branch this PR currently uses vs others I have.

[rpardini]

it's not used in this branch

Yeah, but reviews are costly -- please don't waste our time, it's precious. Thanks.

[JohnTheCoolingFan]

Yeah, but reviews are costly -- please don't waste our time, it's precious. Thanks.

When the PR is ready for review, I'll mark it as such. For now - it's a draft.

[rpardini]

Well I sent #6874 (also draft) - I don't (or plan to) have the board

[JohnTheCoolingFan]

Switched it to the @rpardini config. The built image does boot but there is no hdmi output, no ethernet connection and I still can't get proper input via UART pins. I don't have dedicated usb-to-uart converters yet and have been using a chinese arduino nano clone with a ch340 chip and the MCU reset pin tied to ground. I can get board's output butt can't input anything.

[JohnTheCoolingFan]

Noticed that BTT had a custom armbianEnv.txt and there was overlay=hdmi, tried setting this in the image, didn't make the hdmi work.

I'm getting out of ideas. The device tree is same, based on the same kernel, so why is it not giving any output? The config is set to have output on both serial and display. And also Ethernet doesn't work even though it probably uses the same exact driver (based on 6.6 kernel).
Some help would really be appreciated. I can probably safely use an arduino to read serial output but not send until a proper usb-uart adapter comes in.

[JohnTheCoolingFan]

Tried vendor's image, a minimal Armbian build. It had a lot of additional device tree overlays, including hdmi, which did get me a working hdmi output, but simply putting overlays=hdmi doesn't enable that output on the armbian build of this commit.
Also, I couldn't get any hardware UART from it even with a dedicated USB to UART adapter bases on a FT232RL chip. It didn't work on the vendor image and didn't work on the PR's commit build, even trying different UARTs and speeds (25000000, 15000000, 1500000, 115200, 9600).

[igorpecovnik]

but simply putting overlays=hdmi doesn't enable that output on the armbian build of this commit.

What if you put HDMI to device tree?

[JohnTheCoolingFan]

It's already in the device tree: https://github.com/armbian/build/pull/6860/files#diff-d2416d7f0b4589c184941fa192bd7b1fd0baf0adbcf15b42f235be3fb728918cR262-R282 and https://github.com/armbian/build/pull/6860/files#diff-d2416d7f0b4589c184941fa192bd7b1fd0baf0adbcf15b42f235be3fb728918cR26-R35

[JohnTheCoolingFan]

Ok, I finally got some progress with getting a tty. I shouldn't have traced down the gpio pins from rk3566 datasheet, the tx/rx pins are the same as in Btt Pi (CB1) or CM4. The pins are not marked as uart in the official manual, which just makes it extremely confusing. I now have a fully functional tty and can debug problems further.

Alright, so now I would like to first set up ethernet so I don't have to use uart as often. In the current config, the board is having problems setting up ethernet:

[   23.648519] rk_gmac-dwmac fe010000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   23.650924] rk_gmac-dwmac fe010000.ethernet eth0: PHY [stmmac-0:00] driver [YT8531 Gigabit Ethernet] (irq=POLL)
[   24.651122] rk_gmac-dwmac fe010000.ethernet: Failed to reset the dma
[   24.651145] rk_gmac-dwmac fe010000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
[   24.651152] rk_gmac-dwmac fe010000.ethernet eth0: __stmmac_open: Hw setup failed
[   25.189408] rk_gmac-dwmac fe010000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   25.191615] rk_gmac-dwmac fe010000.ethernet eth0: PHY [stmmac-0:00] driver [YT8531 Gigabit Ethernet] (irq=POLL)
[   26.195094] rk_gmac-dwmac fe010000.ethernet: Failed to reset the dma
[   26.195115] rk_gmac-dwmac fe010000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
[   26.195122] rk_gmac-dwmac fe010000.ethernet eth0: __stmmac_open: Hw setup failed

[JohnTheCoolingFan]

Putting the boot log gist here just for the record: https://gist.github.com/JohnTheCoolingFan/5df87cc4b87298d6bc21e046bfcff5f6

[JohnTheCoolingFan]

Rebased for rockchip64-6.12. I've also made attempts modifying u-boot or kernel device trees to fix the freezing issue. I tried changing voltage regulator definitions. Some resulted in error to boot, some made no difference at all.

I also found some peculiar details, or maybe even conflicts between the device trees:

1. Pin gpio0 RK_PC5 is used for vcc5v0_host in the u-boot device tree but that pin is used as snps,reset-gpio in kernel device tree. The GPIO mode is different: GPIO_ACTIVE_HIGH in u-boot and GPIO_ACTIVE_LOW in kernel. For further tests, I could try disabling the gmac1 node and see what happens.
2. Kernel device tree and u-boot device tree don't seem to share usb voltage regulators pinctrl at all: 0 RK_PC5 in u-boot and 0 RK_PB5, 0 RK_PB6, 4 RK_PC6 and 4 RK_PC4 in kernel.

These might be clues to voltage regulators being misconfigured in one or the other, or even gpio being an issue.

One of earlier hints of voltage regulators being misconfigured is from dmesg:

[    0.735069] debugfs: Directory 'vcc5v0_host' with parent 'regulator' already present!
[    0.735675] debugfs: Directory 'vcc5v0_host' with parent 'regulator' already present!
<...>
[    2.310654] rk808-regulator rk808-regulator.2.auto: there is no dvs0 gpio
[    2.311300] rk808-regulator rk808-regulator.2.auto: there is no dvs1 gpio
<...>
[   11.449100] edt_ft5x06 2-0038: supply vcc not found, using dummy regulator
[   11.449964] edt_ft5x06 2-0038: supply iovcc not found, using dummy regulator
[   11.450431] edt_ft5x06 2-0038: touchscreen probe failed

I am a bit confused on how problematic these messages are, especially the latter two. The first one seems to just be a conflict of... Something. Although these messages are present in both images.
I'll also record the dmesg of a boot with bigtreetech u-boot to be able to compare against each other.

Edit:

• Boot with mainline: https://paste.next.armbian.com/uquxiriheh
• Boot with bigtreetech: https://paste.next.armbian.com/acilusubum

Right now I'm going to sleep and planning to attempt further debugging later. Hopefully not Sisyphus style.

[JohnTheCoolingFan]

While the freezing problem is annoying, there is still some stuff to fix. I've fixed a bunch of stuff reported in dmesg and attempted various tweaks to help with the problem of freezing.

New problems:

• Sometimes when rebooting I get a kernel panic: https://paste.next.armbian.com/pufehufega
• Non-fatal error that I don't know the meaning of in u-boot: rockchip_rk3066_i2c i2c@fdd40000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
• kernel errors about rk809_sound:

  [   11.775546] asoc-simple-card rk809-sound: ASoC: Failed to add route MICBIAS1(*) -> Mic Jack(*)
  [   11.775572] asoc-simple-card rk809-sound: ASoC: Failed to add route Mic Jack(*) -> IN1R(*)
  [   11.775581] asoc-simple-card rk809-sound: ASoC: Failed to add route HPOL -> Headphone Jack(*)
  [   11.775590] asoc-simple-card rk809-sound: ASoC: Failed to add route HPOR -> Headphone Jack(*)
  

Fixed:

• debugfs: Directory 'vcc5v0_host' with parent 'regulator' already present! was fixed by giving unique regulator-name to each regulator
• platform rk809-sound: deferred probe pending: asoc-simple-card: parse error which I think also solves hdmi sound problem but I'm not sure.

I do admit I over-fixated on the critical problem and was ignoring the smaller issues that could be quickly investigated, fixed and checked. Although it might seem that not fixing the major problem is less effective, it is effective to spend some time on smaller issues because I can't find info on the major problem for a long time.

Maybe it's something about the u-boot loading the kernel and then something is trying to switch at 170 seconds. I don't have enough knowledge on u-boot and the loading process to know what it is, and research is slow. Bringing back the "help needed" label.

[rpardini]

• current using vendor u-boot due to "magic gremlins" but otherwise board works fine (Ethernet, serial, nvme, emmc, etc)
• edge is left for experiments on trying to get mainline u-boot working.

I'd say having a current (with vendor u-boot and mainline kernel) that enables people to get going is good enough to merge, if you're willing to squash some/most of those 28 commits ;-) And yes you can keep on working on edge calmly.

It's really important to send the contributions upstream, as there are way more people who can help on the kernel/u-boot mailing lists.

[JohnTheCoolingFan]

I've sent the current 6.6 kernel device tree to the linux-rockchip mailing list as a patch and subscribed to the mailing list. I did not receive any replies on it, but the patch did get posted, so I have no idea whether it will get accepted or not. I will continue improving the device tree, benefitting all branches, both current and edge. There is some stuff missing compared to the vendor's image based on 4.19. There are some features I can't test, like csi and dsi interfaces, but most of the stuff is not problematic. I will squash some of the patches and commits.