Orange Pi Zero 3

[Gunjan Gupta]

As you mentioned you had a serial adapter plugged into zero2 but not to the pc, its possible that the uart adapter might have sent some garbage character just when it says press any key to stop booting and hence it got stopped there. I have seen that happens sometimes when my serial adapters usb plug touches some metal or when I touch the same.

[pixdrift]

38 minutes ago, Gunjan Gupta said:

I have seen that happens sometimes when my serial adapters usb plug touches some metal or when I touch the same.

Possibly, but the USB end isn't touching anything, and it's consistent/reliable (ie. it impacts every boot). I assume it's something to do with the design of the converter. Anyway, it's a known quantity now so I can rule out those issues.

From my perspective, everything is testing successfully on the Zero2 so wondering if we should discuss merging or is there more you want to focus on?

I was thinking as I was working with the Zero2 that it might be nice to have an LED enable/disable (or function change) in the hardware menu? Not sure if others would find that useful.

[sander]

I am a Zero2W user (2gb version, h618). Is there anything that requires testing?

Edited January 18 by sander

[Stephen Graf]

@pixdrift If your serial to usb adapter is not connected on the usb side, where is it getting power from?  This could be a cause for possible garbage characters appearing on the input of the serial side that would stop u-boot.  It is also possible for the serial side to oscillate (if not powered) just from the voltages on the output pin and u-boot is trying to decode a lot of garbage.

 

Bus usb@5200400: USB OHCI 1.0
scanning bus usb@5200000 for devices... 2 USB Device(s) found
scanning bus usb@5200400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Autoboot in 2 seconds, press <Space> to stop
Card did not respond to voltage select! : -110

 

Regarding an overlay for the leds. Currently in the dtb the leds are defined as:

 

        leds {
                compatible = "gpio-leds";

                led-0 {
                        function = "status";
                        color = <0x01>;
                        gpios = <0x14 0x02 0x0c 0x00>;
                        linux,default-trigger = "heartbeat";
                };

                led-1 {
                        function = "power";
                        color = <0x02>;
                        gpios = <0x14 0x02 0x0d 0x00>;
                        default-state = "on";
                };
        };

 

What would you propose? Overlays can add or change existing lines.  They can not remove lines.

 

My recommendation is to just leave them as they are.  There is a option to add user defined overlays. Check out the /boot/boot.cmd:

 

for overlay_file in ${user_overlays}; do
        if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then
                echo "Applying user provided DT overlay ${overlay_file}.dtbo"
                fdt apply ${load_addr} || setenv overlay_error "true"
        fi
done

 

There is a catch. If the user overlay messes up the dtb is restored to the state before even the kernel overlays have been added!

 

I think I would like to prepare the overlay patch as a PR to the Armbian master.

 

 

 

 

 

 

 

[pixdrift]

10 hours ago, Stephen Graf said:

I think I would like to prepare the overlay patch as a PR to the Armbian master.

 

Agreed to leave the LEDs as they are for now.

 

As for the PR, given that Zero2 is a supported board, we should probably also add this change to the other kernels the Zero2 supports (and test), ie. legacy and current.

https://github.com/armbian/build/blob/e73c0b6514db5c55d896e62112f578214e7f30cb/config/boards/orangepizero2.conf#L7

We can use the merge request I have and stage it as a PR, or you're more than welcome to create your own (even off mine if you like), let me know how you want to proceed.

[pixdrift]

19 hours ago, sander said:

I am a Zero2W user (2gb version, h618). Is there anything that requires testing?

Hi sander, welcome to the forum! Thanks for introducing yourself, always good to know there are others around willing to assist with testing

I'd say you're in the right place as I think Zero2W is where (at least my) focus will shift to next, just a bit early as we don't have anything to test.

As has been discussed in the thread, @Gunjan Gupta did some preliminary work in his own repo to get the Zero2W working, but I haven't had time to go through it and prepare a more formal patch for Armbian.
https://github.com/viraniac/armbian_build/tree/zero2w

This repo is provided with no support, as it's in heavy development, but if you wanted something to work with, this may help.

[MrK]

Hi everyone,

 

I gave a try to SPI1 on my zero 3 with 2GB, used for that https://github.com/armbian/build.git, 

commit e73c0b6514d

 

I did not attach any device just logic analyzer. Results are that sck, mosi do work even at 100MHz rate, the speed limit in overlays is ignored.

Hold time (mosi - sck) is about 1ns measured with 500ps resolution. 100MHz on sck is exactly 100MHz (again 500ps resolution) which stands for that all PLL chains and dividers are setup properly.

10 clock periods equal to 99.99ns !

The only odd thing is that I can not figure out where spi cs output is. I gave a try to PH3 however there was no activity related to spi. I also checked PH9 and it does not work too.

 

I wonder if I missed something - did I use wrong overlay for example ? (overlays=spi-spidev spidev1_0)

Or there is something "almost there" with pin-mux ?

 

Greetings from Poland

 

[MrK]

Wifi 5622 gets stuck on scan in AP mode..

 

I guess there must be some rogue AP nearby me .. and the issue starts with WCN: mdbg_assert_read:WCN Assert in rf_marlin.c line 1016, pri20_offset == NO_OFFSET,data length 128

followed by dump of registers 5622 so finally 5622 enters /dev/null

 

here is hostapd output:

wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
wlan0: Setup of interface done.
ctrl_iface not configured!
RTM_NEWLINK: ifi_index=3 ifname=wlan0 operstate=6 linkmode=1 ifi_family=0 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
nl80211: Drv Event 15 (NL80211_CMD_START_AP) received for wlan0
wlan0: nl80211: Ignored unknown event (cmd=15)
nl80211: Drv Event 33 (NL80211_CMD_TRIGGER_SCAN) received for wlan0
wlan0: nl80211: Scan trigger
wlan0: Event SCAN_STARTED (47) received
Unknown event 47
nl80211: Drv Event 35 (NL80211_CMD_SCAN_ABORTED) received for wlan0
wlan0: nl80211: Scan aborted
nl80211: Scan probed for SSID ''
nl80211: Scan included frequencies: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825
wlan0: Event SCAN_RESULTS (3) received

 

 

and attached is kernel log.

rogue-ap.dmesg

[Stephen Graf]

@MrK You should try the build from  @pixdrift (edge only).

https://github.com/pixdrift/armbian_build/tree/zero23_spi_menufix

 

There is only one overlay item for spi, spi1, PH6,7,8 and cs0, which is on PH9 as per the orangepizero2/3 drawings.

 

I have not put a scope on the pins but tested with spidev_test and a loopback on SI/SO which returns the correct data. I also put a meter on PH9 and it goes high during the test.

Edited January 20 by Stephen Graf
clarification

[Stephen Graf]

@pixdrift If you want to proceed with a PR please go ahead.  If you apply the patch to your repo I will build and test on current for the zero3.

 

I still have concerns with a number of items that might be related:

- Bluetooth only working on the initial boot

- pinctl errors on boot

- dmesg log not starting at time 0.

[pixdrift]

3 hours ago, Stephen Graf said:

If you want to proceed with a PR please go ahead.  If you apply the patch to your repo I will build and test on current for the zero3.

Thanks @Stephen Graf, my branch has been updated with mainline and I have added the patches for both 'legacy' (6.1) and 'current' (6.6) kernels, although I haven't yet created test builds. I will create builds and test zero2, if you can cover off zero3?

https://github.com/pixdrift/armbian_build/tree/zero23_spi_menufix

 

 

In unrelated updates, I also received some mail so I now have the HDMI audio splitter for potentially testing the HDMI audio patch (but the size of the patch is a little daunting), and the Sipeed Longan (not related to this thread other than it's also H618) looks like a great board!

[Stephen Graf]

@pixdrift Thank you. I will test current on zero3.  I don't think zero3 is supported on legacy.

 

I have a monitor with hdmi and audio and can test sound over hdmi on zero3.  I can also test analog sound from the header if the sound fix works for both.

[pixdrift]

It seems I have confused legacy.. when I built 'current' it's 6.6.12, not sure if 6.1 is still used? as 'legacy' build for zero2 was 4.9.318 I will need to take another look at how patches are done for legacy, or if we just don't support it.

[ag123]

actually that in mainline, there are various dts changes e.g. zero 2w that are in versions > 6.6 e.g. 6.7, as 6.6 is LTS, I'm wondering how would those be merged into lts as well.

would mainline backport those 6.7 etc patches say for zero 3, zero 2w into 6.6 lts?

and that after all based on this announcement

'current' would after all be 6.6 LTS?

and i'd suppose 6.1 would be 'legacy' ? lol

 

as i got a little curious about this, i start looking at kernel git logs

if we consider linux-sunxi as 'upstream' 6.6

https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-6.6

Quote

2023-08-06arm64: dts: allwinner: h616: Add OrangePi Zero 3 board supportAndre Przywara2-0/+95

2023-08-06dt-bindings: arm: sunxi: document Orange Pi Zero 3 board nameAndre Przywara1-0/+5

2023-08-06arm64: dts: allwinner: h616: Split Orange Pi Zero 2 DTAndre Przywara2-118/+135

then that of course 'for-next' is 'edge'

https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/for-next

Quote

2023-11-18arm64: dts: allwinner: h616: update emac for Orange Pi Zero 3sunxi-fixes-for-6.7-1sunxi/fixes-for-6.7Chukun Pan3-3/+5

2023-11-18clk: sunxi-ng: nkm: remove redundant initialization of tmp_parentsunxi-clk-for-6.8-1sunxi/clk-for-6.8Colin Ian King1-3/+2

2023-11-18arm64: dts: allwinner: h616: add Orange Pi Zero 2W supportAndre Przywara1-0/+176

 

then that 'mainline' 6.6 (tag)

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v6.6&qt=grep&q=h618

Quote

2023-08-06arm64: dts: allwinner: h616: Add OrangePi Zero 3 board supportAndre Przywara2-0/+95

2023-08-06dt-bindings: arm: sunxi: document Orange Pi Zero 3 board nameAndre Przywara1-0/+5

and that in 'mainline' 'master' (branch)

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=h618

Quote

8 daysMerge tag 'soc-dt-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds806-5093/+53237

2023-12-21Merge tag 'sunxi-dt-for-6.8-1' of https://git.kernel.org/pub/scm/linux/kernel...Arnd Bergmann5-0/+350

2023-12-14arm64: dts: allwinner: h618: add Transpeed 8K618-T TV boxAndre Przywara2-0/+162

2023-12-14dt-bindings: arm: sunxi: document Transpeed 8K618-T board nameAndre Przywara1-0/+5

2023-11-18arm64: dts: allwinner: h616: add Orange Pi Zero 2W supportAndre Przywara1-0/+176

2023-11-18dt-bindings: arm: sunxi: add Orange Pi Zero 2WAndre Przywara1-0/+5

2023-08-06arm64: dts: allwinner: h616: Add OrangePi Zero 3 board supportAndre Przywara2-0/+95

2023-08-06dt-bindings: arm: sunxi: document Orange Pi Zero 3 board nameAndre Przywara1-0/+5

 

as i searched specifically for H618 as keyword, chances are that I missed out other related changes. But that the dts changes are found in the 'h618' keyword searches.

it'd seem that Armbian 'edge' (e.g. 6.7) would be in line with around 6.7 where Zero 2W is added to the dts.

but that 6.6 would only have Zero 3 dts.

 

either way, I think we made some further changes here?

or rather that for 'current' it would be 'frozen' at 6.6 and things on top of that added as patches ? e.g. possibly the dts changes?

 

a curious situation is such that we are here currently possibly further 'upstream' of linux-sunxi lol

 

[Werner]

6 minutes ago, ag123 said:

legacy

 

"legacy" is a term that thas been established years ago when there wasn't much confusion about it. However things have changed and now it is, depending on board family, either an old-LTS just for historical purpose or a vendor kernel which may or may not significantly outdated but working.

Anyway there are discussion about renaming that into "vendor" or something, however the impact would be huge if not done carefully.

 

6 minutes ago, ag123 said:

mainline

If anyone steps up doing, testing and maintaining this, why not? We won't simply due to lack of human resources.

[ag123]

thanks @Werner, then I'd guess it'd be good to leave 'legacy' as 'legacy' (e.g. don't replace with 6.1)

my guess is it'd be ok (for most) if 'current' is simply 6.6, and all the stability fixes goes into 6.6, there is no need to insist on a 6.1 etc, but i'd guess it may be good/adequate if it (6.1) is kept somewhere e.g. say in git so that that particular version can be checked out for posterity in case that when moving to 6.6, 'something gets left behind'.

 

[pixdrift]

I am going to pull the 6.1 patches as for zero2 and zero3 they look like dead code (not used by 'current' or 'edge' for these boards) and I don't think it's worth patching the legacy 4 kernel.

Will update my branch by pulling the 6.1 patches and raise the PR after testing.

 

-edit-

 

This has been validated now on zero2 + current with the 6.6.12
 

Boot script loaded from mmc
264 bytes read in 2 ms (128.9 KiB/s)
32009 bytes read in 6 ms (5.1 MiB/s)
Working FDT set to 4fa00000
344 bytes read in 5 ms (66.4 KiB/s)
Applying kernel provided DT overlay sun50i-orangepizero2-3-i2c3.dtbo
339 bytes read in 5 ms (65.4 KiB/s)
Applying kernel provided DT overlay sun50i-orangepizero2-3-ir.dtbo
608 bytes read in 5 ms (118.2 KiB/s)
Applying kernel provided DT overlay sun50i-orangepizero2-3-otg-host.dtbo
699 bytes read in 4 ms (169.9 KiB/s)
Applying kernel provided DT overlay sun50i-orangepizero2-3-spi1-cs0-spidev.dtbo
644 bytes read in 5 ms (125 KiB/s)
Applying kernel provided DT overlay sun50i-orangepizero2-3-uart5.dtbo
620 bytes read in 6 ms (100.6 KiB/s)
Applying kernel provided DT fixup script (sun50i-orangepizero2-3-fixup.scr)
## Executing script at 45000000
18377497 bytes read in 761 ms (23 MiB/s)
22964232 bytes read in 953 ms (23 MiB/s)
Moving Image from 0x40080000 to 0x40200000, end=41860000
## Loading init Ramdisk from Legacy Image at 4ff00000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    18377433 Bytes = 17.5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
Working FDT set to 4fa00000
   Loading Ramdisk to 48e79000, end 49fffad9 ... OK
   Loading Device Tree to 0000000048e08000, end 0000000048e78fff ... OK
Working FDT set to 48e08000

Starting kernel ...

 

Edited January 20 by pixdrift

[pixdrift]

@Stephen Graf PR 6182 is now submitted and waiting on review and your testing feedback on Zero3 (no rush ) 

https://github.com/armbian/build/pull/6182

[MrK]

@Stephen Graf Thank you for hint. I took the branch, commit a9c3f68200fb06dd as you advised and the good news are that CS0 on PH9 is being driven.

bad news are that it goes active abt. 2us before 1st clock and goes inactive abt 2000ms (yes, 2 secs) after last clock,

still the same speed 100Mbps, default settings. /dev/spidev1.0: mode=0, lsb=0, bits=8, speed=100000000, spiready=0 and single spi-pipe request with one block of 4 bytes size. (the 0xdeadbeef)

I was thinking the spi is something I may look into driver and think how to improve CS latency. Looks like it is software driven.

I would like to have a choice of selecting CS active state level. I don't know if H616/618 allows to do that. Need to look for some reference manual.

 

just in case one was curious - what these white  and green traces are: white are collected by, let's call it, master LA which has sampling clock up to 333MHz by default and large memory: 2Mx64 bits, it works in "transitional" mode which is very useful in this case.

(2M samples memory @ 333MHz wouldn't last for 2 secs if data was stored sequentially)

green traces are recorded by auxiliary LA instance which samples inputs at 2GHz once triggered and has limited memory of 16k samples (x64). This is why these white and green traces are a bit shifted in time and green are short due to aux LA memory size.

(however time resolution is decent: 500ps)

 

wifi issue persists.

 

 

[Stephen Graf]

@MrK Try the spidev_test tool.  It has many options to set various parameters such as speed.

 

https://github.com/rm-hull/spidev-test/blob/master/README.md

 

[jokubas.ver]

Any reason why the mali gpu node is disabled by default (i.e. status is not set to 'okay')? https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-6.7/patches.armbian/arm64-dts-sun50i-h618-orangepi-zero3-Enable-GPU-mali.patch

I have successfully tested 3D acceleration on Zero3, seems to be working fine.

[Gunjan Gupta]

23 minutes ago, jokubas.ver said:

Any reason why the mali gpu node is disabled by default (i.e. status is not set to 'okay')? https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-6.7/patches.armbian/arm64-dts-sun50i-h618-orangepi-zero3-Enable-GPU-mali.patch

I have successfully tested 3D acceleration on Zero3, seems to be working fine.

I guess copy paste error from Orange Pi's repository. I do remember changing it to ok, but I guess I forgot to include that in the commit.

[pixdrift]

1 hour ago, jokubas.ver said:

Any reason why the mali gpu node is disabled by default (i.e. status is not set to 'okay')? https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-6.7/patches.armbian/arm64-dts-sun50i-h618-orangepi-zero3-Enable-GPU-mali.patch

I have successfully tested 3D acceleration on Zero3, seems to be working fine.

Hi @jokubas.ver, welcome to the forum and thanks for spotting this. As @Gunjan Gupta mentioned it was probably a minor mistake as there was some juggling of these files initially and it looks like people may not have tested this at this point (but great you have!).

 

When you say you've tested, have you tested using Armbian from the official build repo with this flag set to 'okay' or with another build? If it's this build, it will be a PR to resolve it, and I am happy to put raise that or assist you with raising it if you need a hand.

Can you let us know which branch you built off and some details of your board version and OS/configuration combination you used for your test? Details of the tests you ran would also be really helpful for others reading this thread and if we need to replicate them when the PR is raised.

Thanks again!

Edited January 21 by pixdrift

[jokubas.ver]

Hi, the commit was merged: https://github.com/armbian/build/commit/1023f9d4204a4cd229a01a6dec498642f6790e43

@pixdrift The build I was using was one of your newer ones, tested by editing the dtb in armbian config. To check if gpu works, I tested with lsmod and Supertuxkart, works fine. 

[pixdrift]

4 hours ago, jokubas.ver said:

@pixdrift The build I was using was one of your newer ones, tested by editing the dtb in armbian config. To check if gpu works, I tested with lsmod and Supertuxkart, works fine. 

 

Excellent! thanks for your contribution to the Orange Pi work and registering on the forum to let us know, it's greatly appreciated. 

[ag123]

hi all,

 

I'd just like to say that it is now possible to build Armbian for Orangepi Zero 3 from source from the trunk

https://github.com/armbian/build

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

select

• bookworm
• edge 6.7

for the build

 

but that it is necessary to run with

compile.sh EXPERT=yes

 

 

special thanks goes to 

@pixdrift

@Gunjan Gupta

and the armbian maintainers many @Igor et.al https://github.com/armbian/build/graphs/contributors

 

in case anyone is curious about the resulting built image for tests, etc- note *unsupported* *use at your own risk*

Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.1_minimal20240122.img is an **unsupported** Armbian image build from the trunk (i.e. main branch) from
https://github.com/armbian/build from 20240122 for Orangepi Zero3 - Debian Bookworm image

https://www.mediafire.com/file/5kqetzxkqe2kk5i/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.1_minimal20240122.7z/file

this won't be there permanently

 

note that as @Gunjan Gupta mentions (below), actually there are nightly builds. It is recommended to use those instead for tests.

https://github.com/armbian/os/releases/latest

[pixdrift]

After discussion in PR6182, I have written the following patch to enable all these features (except usb otg) by default to remove the need for overlays.

https://github.com/pixdrift/armbian_build/tree/zero23_enable_all

I have also updated the SPI pin in the h616 dtsi so it specifies PH9 correctly.

 

If you look at the patch, it also cleans up the configuration considerably.. with the philosophy that if everything on the SoC is the same between h616, we should move the configuration up to there, and only have 'status = okay' at the board level to enable/disable the features. I have done that in this implementation.

My only concern is SPI, which I have left in the board configuration for now, but I am concerned with inconsistency of these two entries (the lower entry for spi1 is taken from the overlay patch). I feel that the address-cells and size-cells entries should be at the same level in the hierarchy in both and numeric values are specified differently between both. @Stephen Graf I also removed the 'status = okay' at the spidev@0 level from your overlay patch because it didn't seem consistent with any other configurations I could fine (but let me know if it does/doesn't work as it is).

 

&spi0 {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>;

        flash@0 {
                #address-cells = <1>;
                #size-cells = <1>;
                compatible = "jedec,spi-nor";
                reg = <0>;
                spi-max-frequency = <40000000>;
        };
};

&spi1 {
        status = "okay";
        #address-cells = <0x01>;
        #size-cells = <0x00>;
        pinctrl-names = "default";
        pinctrl-0 = <&spi1_pins &spi1_cs0_pin>;

        spidev@0 {
                compatible = "rohm,dh2228fv";
                reg = <0x00>;
                spi-max-frequency = <0xf4240>;
        };
};

-edit-

So this is probably worth abandoning before raising a new PR, I just read @Gunjan Gupta's post from the PR
 

Quote

No, I am not ok with that. Someone might only require normal gpio access, some might only require i2c and some only might have use for uart or pwm. Enabling everything is not a good idea.

https://github.com/armbian/build/pull/6182#issuecomment-1903672798

Edited January 22 by pixdrift

[ag123]

ouch, those things gets tricky really, in the way that the 2 spi interfaces are declared, it is correct to say that one of the spi goes to the spi flash (e.g. an MTD) device.

while the other is possibly simply on the headers?

I'm not familiar with dts really, but that the first declaration would 'chain' another driver say the spi flash driver that uses it?

but I'd imagine that the spi are at the 'same level' as mentioned, just that for instance maybe the orange pis possibly use a SPI flash for the boot rom, while it may be different or even possibly just a different port say on the bigtreetech board?

 

and so I went googling again, and stumbled into this

https://elinux.org/Device_Tree_Usage#Non_Memory_Mapped_Devices

Non Memory Mapped Devices
Other devices are not memory mapped on the processor bus. They can have address ranges, but they are not directly accessible by the CPU. Instead the parent device's driver would perform indirect access on behalf of the CPU.

To take the example of i2c devices, each device is assigned an address, but there is no length or range associated with it. This looks much the same as CPU address assignments.

        i2c@1,0 {
            compatible = "acme,a1234-i2c-bus";
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <1 0 0x1000>;
            rtc@58 {
                compatible = "maxim,ds1338";
                reg = <58>;
            };
        };

 

https://android.googlesource.com/kernel/msm/+/android-wear-5.0.2_r0.1/Documentation/devicetree/bindings/spi/spi-bus.txt

Spoiler

SPI (Serial Peripheral Interface) busses

SPI busses can be described with a node for the SPI master device

and a set of child nodes for each SPI slave on the bus. For this

discussion, it is assumed that the system's SPI controller is in

SPI master mode. This binding does not describe SPI controllers

in slave mode.

 

The SPI master node requires the following properties:

- #address-cells - number of cells required to define a chip select

address on the SPI bus.

- #size-cells - should be zero.

- compatible - name of SPI bus controller following generic names

recommended practice.

- cs-gpios - (optional) gpios chip select.

 

No other properties are required in the SPI bus node. It is assumed

that a driver for an SPI bus device will understand that it is an SPI bus.

However, the binding does not attempt to define the specific method for

assigning chip select numbers. Since SPI chip select configuration is

flexible and non-standardized, it is left out of this binding with the

assumption that board specific platform code will be used to manage

chip selects. Individual drivers can define additional properties to

support describing the chip select layout.

 

Optional property:

- num-cs : total number of chipselects

 

If cs-gpios is used the number of chip select will automatically increased

with max(cs-gpios > hw cs)

 

So if for example the controller has 2 CS lines, and the cs-gpios

property looks like this:

cs-gpios = <&gpio1 0 0> <0> <&gpio1 1 0> <&gpio1 2 0>;

 

Then it should be configured so that num_chipselect = 4 with the

following mapping:

cs0 : &gpio1 0 0

cs1 : native

cs2 : &gpio1 1 0

cs3 : &gpio1 2 0

 

SPI slave nodes must be children of the SPI master node and can

contain the following properties.

- reg - (required) chip select address of device.

- compatible - (required) name of SPI device following generic names

recommended practice

- spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz

- spi-cpol - (optional) Empty property indicating device requires

inverse clock polarity (CPOL) mode

- spi-cpha - (optional) Empty property indicating device requires

shifted clock phase (CPHA) mode

- spi-cs-high - (optional) Empty property indicating device requires

chip select active high

- spi-3wire - (optional) Empty property indicating device requires

3-wire mode.

 

If a gpio chipselect is used for the SPI slave the gpio number will be passed

via the cs_gpio

SPI example for an MPC5200 SPI bus:

spi@f00 {

    #address-cells = <1>;

    #size-cells = <0>;

    compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";

    reg = <0xf00 0x20>;

    interrupts = <2 13 0 2 14 0>;

    interrupt-parent = <&mpc5200_pic>;

    ethernet-switch@0 {

        compatible = "micrel,ks8995m";

        spi-max-frequency = <1000000>;

        reg = <0>;

    };

    codec@1 {

        compatible = "ti,tlv320aic26";

        spi-max-frequency = <100000>;

        reg = <1>;

    };

};

 

another example found here for stm32

https://wiki.st.com/stm32mpu/wiki/SPI_device_tree_configuration

 

based on those hints, my guess

&spi0 {
        status = "okay";
        #address-cells = <1>; //one number to indicate the chip select pin
        #size-cells = <0>; //zero as given in the blurb from google android
        pinctrl-names = "default";
        pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>;

        flash@0 {
                compatible = "jedec,spi-nor";
                reg = <0>; //chip select of '0'(zero)
                spi-max-frequency = <40000000>;
        };
};

&spi1 {
        status = "okay";
        #address-cells = <0x01>;
        #size-cells = <0x00>;
        pinctrl-names = "default";
        pinctrl-0 = <&spi1_pins &spi1_cs0_pin>;

        spidev@0 {
                compatible = "rohm,dh2228fv";
                reg = <0x00>;
                spi-max-frequency = <0xf4240>;
        };
};

 

 

 

[Gunjan Gupta]

3 hours ago, ag123 said:

hi all,

 

I'd just like to say that it is now possible to build Armbian for Orangepi Zero 3 from source from the trunk

https://github.com/armbian/build

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

There is actually no need to build the image yourself. You can just download the latest nightly release from https://github.com/armbian/os/releases/latest

[ag123]

@Gunjan Gupta

Thanks !