Quartz64-zero build

General Discussion
1

Creating a software or image request, pls use GitHub

Any chance of a Quartz64-zero DTB ? the quartz64-a boots but usb is not working/

There people have the possibility to vote on your request :wink:

2

Mainline Linux does not contain that device tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip

The PINE64 Armbian fork does not seem to support it either: GitHub - pine64/build: PINE64 Armbian build customizations · GitHub

Do you have source for that device tree?

3

No, i don’t
The quartz64-a boots but the usb doesnt power on. The pine android 13 works=
but i dont have a tool to extract the dtb frm it. Most importantly im pret=
ty sure i don’t know enough about this.

4

For reference:

And I asked on Discord. Someone mentioned to work on upstream support, hence might have a device tree draft already.

Another problem is the AIC8800 onboard WiFi chip. There are sources from Radxa which work with mainline Linux: GitHub - radxa-pkg/aic8800: Aicsemi aic8800 Wi-Fi driver. Official support for Radxa devices only. · GitHub
But the SDIO variant of the driver compiles up to Linux 7.0 only, requires patches for Linux 7.1 and above. I do not have the time or free Copilot tokens left, but if someone else does, here is a patch for the USB variant of the driver: aic8800/debian/patches/fix-linux-7.1-build.patch at 6e076049b719ac2ff7ce5c92786a680407b11cdb · radxa-pkg/aic8800 · GitHub
That would need to be ported to the SDIO variant.

5

now I am sure I don’t know enough about how this all works. :slight_smile:

6

thank you Ill look into in tomorrow.

7

At the moment, Linux support for this board is not there yet, as PINE64 seems to have focused on Android. Someone had a start working on Linux support, and I would probably be able to get it working as well, based on the Model A/B device trees, and Zero board schematics, so that USB works. But WiFi won’t.

I’ll keep chatting on the Discord channel, but do not expect anything to happen any time soon. If you do find another Linux image for this board (really for the Zero, not Model A/B or SOQuartz), let me know, as this can help.

8

I have a little experience with computers I have a quartz64-b and a quartz64-zero. Where would I go to learn how to alter a dts file using a schematic of a different board. I have a component level repair background with micros and a some knowledge of programming from assembly language stuff. what should i study first. my goal is to be able to make or at least modify a dts file and compile a linux kernel. thanks in advance

9

Here are the mainline Linux device trees for the Quartz64 A/B models:

They mostly enable SoC features exposed on this PCB, which are defined in the RK356x base dtsi: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi

For USB, you see the host controllers for Model A enabled here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts#n775
You find the corresponding nodes defined in the base dtsi here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi#n265
There you can see which PHY and which regulator is attached to which controller. Generally, the board enables all USB controllers for all speeds and sets them to host mode (needed in case of usb_host0_xhci, which is OTG by default.

The Zero schematics are here: https://pine64.sfo3.cdn.digitaloceanspaces.com/doc/quartz64/Quartz64-ZERO_Schematic_v01_20240428.pdf
Most relevant is page 27.

Model A schematics are here to compare: https://files.pine64.org/doc/quartz64/Quartz64_model-A_schematic_v2.0_20210427.pdf
Most relevant is page 26.

There is no vcc5v0_usb30_host in the device tree, only vcc5v0_usb20_host for 3 ports, and vcc5v0_usb20_otg, which seems to be VCC5V0_USB30_HOST in the schematics for the USB 3.0 port, related to usb_host0_xhci. That one seems to be correct for the Zero as well. But it is probably powered differently, the regulator in the schematics is called VCC5V0_USB_HOST1.

To me it looks like, compared to the Model A device tree:

  • usb_host0_xhci > usb2phy0_otg is/needs to be attached to vcc5v0_usb20_host (VCC5V0_USB_HOST1 and VCC5V0_USB20_HOST_2 in the schematics).
  • usb_host0_ehci and usb_host0_ohci > usb2phy1_otg is/needs to be attached to vcc5v0_usb20_otg (VCC5V0_USB_OTG in the schematics).
  • The other USB controllers and PHYs can be probably disabled (just skipped in the final Zero device tree). USB2.0 HOST2 is mentioned in the schematics, but it does not seem to be attached to an actual port, maybe just some pin/connector on the PCB, same with Ethernet? The PCB shows those places beside the USB port, which look like an additional USB and Ethernet port can be soldered there.
  • usb_host1_ehci and usb_host1_ohci seem to be tied to the USB 3.0 port as well, to provide USB 2.0 speed with the legacy interfaces. Hence optional. But the schematics are a bit contradicting there: On page 5 is is shown as combined with “USB2.0 HOST0”, everywhere else with “USB2.0 HOST1”. Or those are for the non-soldered USB2.0 HOST2?

Annoying that no consistent naming is used :thinking:. An alternative interpretation would be:

  • usb_host0_xhci is OTG0 in the schematics, hence attached to the correct regulator already, could be just left at (switched to, compared to Model A dts) dr_mode = "otg".
  • usb_host1_xhci, usb_host0_ehci, usb_host0_ohci are related to the USB 3.0 port, hence wired correctly in the device tree as well.
  • usb_host1_ehci and usb_host1_ohci are related to the non-soldered USB2.0 HOST2.

But then, it would be all correct already, and should work with the Model A device tree.

Actually, the Model B device tree and schematics match a lot better regarding the regulator names, so they could give some clarification:

This tends to point towards the 2nd interpretation. But then I don’t know why it does not work on the Zero. … maybe the GPIOs for the host regulator are wrong:

  • Model A: gpio = <&gpio4 RK_PB5 GPIO_ACTIVE_HIGH>;
  • Model B: gpio = <&gpio0 RK_PC5 GPIO_ACTIVE_HIGH>;

In the Zero schematics, I see

{0E1E52AA-FA89-4F52-8A05-09A864216FC7}

This matches more how it is on the Model B, but still a different one:

{BAEF70BD-6399-4A16-994A-C4AA24A25A55}

  • GPIO0 C5 in schematics => &gpio4 RK_PB5 in device tree

Compared to Model A, where it is indeed GPIO4 B5 => &gpio4 RK_PB5:

{3E8A27B7-2038-4CA5-89F2-A9351F2FA05C}

On the Zero it would then need to be &gpio0 RK_PB6

@Dietpi
This seems to be the hottest attempt to fix USB: If you use the Model A device tree as basis, change the gpio property of the vcc5v0_usb20_host node to <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>.

But the Model B device tree looks closer in this regards. Maybe better start with that one, and change the value accordingly in the vcc5v0_usb30_host node. The change is only RK_PC5 => RK_PB6. And it has usb_host1_ehci and usb_host1_ohci disabled already, which should be correct for the Zero as well.

10

I’ll let you know how this goes. thank you very much.

11

You may reach the Pine Quartz64-zero Android SDK via ftp on my server. Email me for private access details . thank you

12

Hi there, I don’t have any expertise to add here unfortunately but am interested in the progress of this. I’m in a similar boat to OP; have C++ software development experience but no experience with this lower-level stuff. Happy to help test or pitch in with tasks where it would be useful

13

Here the device tree + direct include used for the Android 13 Linux 5.10 image of PINE64:

rk3566-evb2-lp4x-v10.dts.txt (16.6 KB)
rk3566-evb2-lp4x-v10.dtsi.txt (11.5 KB)

These dts(i)s cannot be used directly on mainline Linux. They use different node/symbol names. But when comparing those to the schematics, and the mainline Linux dts(i) for the other Quartz64 boards, they should give a clue about which nodes need which adjustment, or removed.

The Rockchip BSP kernel contains the dts(i) as well. Most nodes have been moved into the dtsi there: linux-rockchip/arch/arm64/boot/dts/rockchip/rk3566-evb2-lp4x-v10.dtsi at 5280f9b4336199c4025c8eed894d2b4e2268dcc6 · armbian/linux-rockchip · GitHub
It shows that a lot has been added by PINE64 in their SDK.

I personally do not feel confident enough to create a device tree from scratch. As the Quartz64 Model A image has been tested already, and it boots just without USB (and WiFi), it is probably easiest/safest to start from there. We should verify that all regulators in the PMIC node have the same voltage limits, and are attached to the same/correct devices. These are programmable regulators, so this is where the kernel can theoretically overvolt components, causing damage. Any nodes definitely not required (Ethernet, audio jack, PCIe port, …) should be removed.

And it needs to use the rk3566t.dtsi instead of the rk3566.dtsi, to remove the unintended 1.6 GHz 1.8 GHz OPP states. Might be some nice overclocking option, but it might degrade the board over time, if the chip and/or surrounding wires are not designed for the 1.1V and 1.15V, compared to 1.025V used for 1.4 GHz, the highest RK3566T OPP state.

The WiFi driver btw just received the needed patch to compile on Linux 7.1 and 7.2: fix building on kernels 7.1 and 7.2 · radxa-pkg/aic8800@bd01abe · GitHub