Gunjan Gupta Posted January 18 Posted January 18 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. 1 Quote
pixdrift Posted January 18 Posted January 18 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. 0 Quote
sander Posted January 18 Posted January 18 (edited) I am a Zero2W user (2gb version, h618). Is there anything that requires testing? Edited January 18 by sander 0 Quote
Stephen Graf Posted January 18 Posted January 18 @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. 0 Quote
pixdrift Posted January 19 Posted January 19 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. 0 Quote
pixdrift Posted January 19 Posted January 19 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. 1 Quote
MrK Posted January 19 Posted January 19 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 0 Quote
MrK Posted January 19 Posted January 19 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 0 Quote
Stephen Graf Posted January 19 Posted January 19 (edited) @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 0 Quote
Stephen Graf Posted January 20 Posted January 20 @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. 0 Quote
pixdrift Posted January 20 Posted January 20 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! 0 Quote
Stephen Graf Posted January 20 Posted January 20 @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. 0 Quote
pixdrift Posted January 20 Posted January 20 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. 0 Quote
ag123 Posted January 20 Author Posted January 20 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 0 Quote
Werner Posted January 20 Posted January 20 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. 2 Quote
ag123 Posted January 20 Author Posted January 20 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'. 0 Quote
pixdrift Posted January 20 Posted January 20 (edited) 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 0 Quote
pixdrift Posted January 20 Posted January 20 @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 0 Quote
MrK Posted January 20 Posted January 20 @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. 0 Quote
Stephen Graf Posted January 20 Posted January 20 @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 0 Quote
jokubas.ver Posted January 21 Posted January 21 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. 1 Quote
Gunjan Gupta Posted January 21 Posted January 21 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. 0 Quote
pixdrift Posted January 21 Posted January 21 (edited) 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 0 Quote
jokubas.ver Posted January 21 Posted January 21 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. 1 Quote
pixdrift Posted January 21 Posted January 21 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. 0 Quote
ag123 Posted January 22 Author Posted January 22 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 0 Quote
pixdrift Posted January 22 Posted January 22 (edited) 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 0 Quote
ag123 Posted January 22 Author Posted January 22 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>; }; }; 0 Quote
Gunjan Gupta Posted January 22 Posted January 22 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 1 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.