5kft

Members
  • Content Count

    148
  • Joined

  • Last visited

About 5kft

  • Rank
    Elite member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. OK, thanks! As I figured, I need to dive in deeper. I'm curious about changes like this, for example: https://lkml.org/lkml/2019/4/3/9... Looks like I have another weekend project to do!
  2. Sure! https://forum.armbian.com/topic/4330-spi-gpio-chip-select-support/ - mid-way in the thread you did some nice debugging into the kernel regarding the initialization of CS. I think I need to do a similar thing to figure out why it simply isn't initializing/working... Perhaps there is no relation, but without digging into spi-gpio yet I'm wondering why it wouldn't initialize correctly...?? "gpioinfo" shows the overlay initialization working in terms of GPIO allocation: line 63: unnamed unused input active-high line 64: unnamed "mosi" output active-high [used] line 65: unnamed "miso" input active-high [used] line 66: unnamed "sck" output active-high [used] line 67: unnamed "spi0 CS0" output active-low [used] line 68: unnamed unused input active-high ...but for example measuring line 67 (PC3) the line is low, when it should be high. Very strange...! Yes, my original test was using several other GPIOs (e.g., PG6/7 for CSN)...same effect.
  3. I'm wondering if anyone has had any luck using spi-gpio to bitbang SPI on the H5... @martinayotte, I found a forum thread from a few years ago where you seemed to be looking at this area - perhaps you have an idea? Doing a typical spi-gpio DT overlay for this properly loads the spi-gpio and spi-bitbang drivers, creates /dev/spidev0.0, and allocates the gpios (verified via gpiod)...but the first problem I see is that the CS line is simply not working (cs-gpios below)...? /dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { spi { compatible = "spi-gpio"; #address-cells = <1>; #size-cells = <0>; ranges; mosi-gpios = <&pio 0 64 0>; /* PC0 */ miso-gpios = <&pio 0 65 0>; /* PC1 */ sck-gpios = <&pio 0 66 0>; /* PC2 */ cs-gpios = <&pio 0 67 1>; /* PC3 */ num-chipselects = <1>; status = "ok"; spidev { compatible = "spidev"; reg = <0>; spi-max-frequency = <500000>; }; }; }; }; }; I'm testing this on a NEO2 using dev kernel 5.3.8, and in this case I am re-using the same standard SPI lines for the HW SPI - this way I can switch between the two easily for testing. Standard HW SPI works great, of course, but the spi-gpio version doesn't. (I tested on other GPIO lines as well and the result is the same.) I hooked the CS, CLK, MOSI, and MISO lines to my scope, and did a test write spi_test through /dev/spidev0.0, and it appears that CLK is properly working, as is the test data transferred via MOSI (at least I'm seeing data bits coming across). But CS simply seems to not be working - I can't trigger properly on it (either high or low). Right off, measuring it shows it as low, when by default it should be high... I am not an expert by any means in this area, so any help/pointers/advice/thoughts would be greatly appreciated! Thanks!
  4. I'm just catching up on this topic... I don't have access to my Zero Plus at the moment but from the picture on Xunlong's site (and my previous experience) it looks like this board has the same HW limitation as the Plus2 - the missing Q5 MOSFET (see red oval highlight in this picture): This problem/limitation is described in this thread: @Darkyere, if it in fact is the case that this part is not included on this board, then unfortunately your board will be limited to a maximum of 1008MHz (for reliable operation). According to the schematic (https://linux-sunxi.org/images/6/67/ORANGE_PI-ZERO-PLUS_V1_0_Schematic.pdf, page 7), the power circuit does include the switching regulator, so it should be capable of providing 1.3v if this part were installed. (Again, refer to the thread I mentioned previously for all details about this.) Igor's guidance of specifying the 1.3v regulator overlay alone is a workaround that will enable the higher clockrate to 1.0GHz. However, without the Q5 MOSFET installed, do not specify the 1.3GHz overclock overlay, as then your board will certainly crash (as you noticed)
  5. Thanks @Igor! I looked into this and it works because the default CPU opp table requires 1.32v starting at clock frequency 1104MHz; this voltage is higher than the 1.30v provided by the regulator overlay, so the higher clock rates will not be enabled. I also confirmed that this works fine on my unmodified board as well
  6. Hi @guidol, I've pushed the change to sunxi-dev: https://github.com/armbian/build/commit/f1cdca27530ed401ff3f5f301aae46155704c85d Enjoy!
  7. Makes sense; I'll merge this new overlay patch in with the existing 1.3GHz patch and should be able to push it tonight. Thanks for testing it!
  8. @Igor - is this a safe change to make for the OPi Zero Plus2 H5? The default H5 CPU frequency opp table now goes to ~1.4GHz, and by adding this regulator overlay you're telling the system that the board has a 1.3v regulator, which by default it likely will not: Perhaps the Armbian default MAX_SPEED= cpufrequtils value will gate this so it will be fine, but I'm not sure if this will happen early enough? I wouldn't be able to check on my unmodified OPi Plus2 physical board until tonight. My thinking in making this an optional overlay was so that people had to really know what they are doing in order to overclock...but perhaps I am being too conservative Just want to make sure...thanks!
  9. Hi @guidol, I made a quick build patch and created two test 1.1v overclock overlays for you for testing. I have attached them to this message in a tarfile. These are built against the 5.3.7 Armbian sunxi-dev kernel; they will not work with -next 4.19 as the opp table definitions are different between these kernels. You can extract this tarfile from the root of your board ("/"), and two overlay files will be extracted into "boot/dtb-5.3.7-sunxi64/allwinner/overlay/": -rw-r--r-- root/root 478 2019-10-30 03:19 boot/dtb-5.3.7-sunxi64/allwinner/overlay/sun50i-h5-cpu-clock-1.0GHz-1.1v.dtbo -rw-r--r-- root/root 562 2019-10-30 03:19 boot/dtb-5.3.7-sunxi64/allwinner/overlay/sun50i-h5-cpu-clock-1.1GHz-1.1v.dtbo Specify the desired one just like for my 1.3GHz overclock overlay; e.g., add these lines to your "/boot/armbianEnv.txt" (this is an example): overlay_prefix=sun50i-h5 overlays=usbhost1 usbhost2 cpu-clock-1.0GHz-1.1v I have included both a 1.0GHz overclock overlay as well as a 1.1GHz overclock overlay. Speeds above 816MHz are set at 1.1v. NOTE: I'm not sure if 1.1GHz at 1.1v is pushing it too much, but I figured you could give it a try if you are feeling adventurous I did a quick test of both of these and they loaded fine, set the clock maximums fine, cpufreq-info works, the board works, etc. Give these a try and let me know how it goes... If these work I could add these to the Armbian build as additional overclock options. H5-overclock-test-dtbs-1.1v.tar.gz
  10. Yes, part of my patch simply creates the 1.3GHz-1.3v overlay included in the dtb package that can be loaded at boot time (it ultimately ends up included in /boot/dtb/allwinner/overlay/ along with all of the other AW overlays). Using overlays like this is really nice because they are optional, and give the user complete control in terms of overclocking. In any case, I can try to look at this later for you when I have an opportunity.
  11. Ah...unfortunately I won't be able to actually look at this until later, and right now I don't have access to source except through git browsing on the web... However, I can try to give you some pointers from memory/github that may help! Here's my patch that creates the 1.3GHz/1.3v overlay (development build): https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/sunxi-h5-add-gpio-regulator-overclock.patch. You can start from this. All that should need to be done to create your 1.0GHz/1.1v overlay is to update the voltages for the entries that you want to change (i.e., 960MHz and 1008MHz). Take a look at https://github.com/megous/linux/blob/orange-pi-5.3/arch/arm/boot/dts/sunxi-h3-h5.dtsi, and find the entries for 960MHz and 1008MHz: opp-960000000 { opp-hz = /bits/ 64 <960000000>; opp-microvolt = <1200000 1200000 1300000>; clock-latency-ns = <244144>; /* 8 32k periods */ }; opp-1008000000 { opp-hz = /bits/ 64 <1008000000>; opp-microvolt = <1200000 1200000 1300000>; clock-latency-ns = <244144>; /* 8 32k periods */ }; You could copy my 1.3GHz overlay, and remove the "opp-" modifications (starting with "opp-1056000000" through "opp-1296000000"), and then insert your own new entries, changing the "1200000" values in "opp-microvolt" for these frequencies to "1100000". Also, I'm not sure at what speed the H5 parts might become unstable at 1.1v, but for fun you could also try modifying the 1.1GHz entry as well, and give it a try perhaps? I hope that this helps!
  12. Indeed! However I think it is 1008 (divisible by 16, and also according to the Xunlong reference and in the existing tables). How it would be nice to have real documentation on this!
  13. This would all be a bit more deterministic (and easier) if there were clear guidelines, and consistency in HW design Unfortunately there doesn't seem to be much to go on. I guess the "best" consideration at this point is the Xunlong SDK note (?): One simple answer (workaround) is to simply provide optional overlays that enable the higher speeds; then this lets the user try this on their boards, and if it works, great! This is one reason I created the 1.3GHz/1.3v overlay; it seems to work fine for people who use it, but if it doesn't, then the board will still always boot and function by default. Perhaps we should include a 1.0GHz/1.1v overlay as well? This would be easy enough to do.
  14. I believe that this is simply a matter of ensuring stability. Not all H5 parts are created equal, so the default ensures that it should be safe for all boards. (See https://groups.google.com/forum/#!topic/linux-sunxi/t7WcMaB3OZY and http://linux-sunxi.org/Xunlong_Orange_Pi_PC_2#CPU_clock_speed_limit, for example.)
  15. Indeed, I took a quick look at the schematic (http://wiki.friendlyarm.com/wiki/images/5/57/NanoPi-NEO2-Black_1907_Schematic.pdf) and noticed a few things (if the schematic is accurate): If the VCC regulator is really a SY8106A (first page notes it is a MP2143DJ, which I'm guessing is a mistake), then the power circuit looks like the same as the NEO Core2, which means that the board may be able to drive the core voltage to 1.4v, meaning it can run up to 1.4GHz (like on the Core2). This is nice! The board "version" GPIO (PL3) is wired the same as the NEO2 v1.1, so for the NEO2 build target this won't allow full speed of the board as this would load the NEO2 v1.1 default DT which actually uses the far more limited MP2143DJ regulator. In fact, with the Black they wired PC4, PC6, and PC7 the same as well as the NEO2 v1.1, which means that we can't do runtime board identification. This likely means that we'll have to do a different board target...