Search the Community
Showing results for 'AR100'.
Found 5 results
-
Starting from: https://github.com/armbian/build/commit/8278dc5e4215a84492dbe297fe243b878a60aaf4 Ref: https://github.com/crust-firmware/crust https://linux-sunxi.org/AR100
-
I had another distro and power button nicely shut down the system and it doesn't with armbian. I have read some things about it but I'm not even sure if they apply to this board or they are updated, about acpi events, logind and AR100, and I've read the official schematics of the board. It seems the button is connected to ADC pins. I installed acpid but acpi_listen reports nothing. But evtest does! root@bananapim5:~# evtest /dev/input/by-path/platform-adc_keys-event Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "adc_keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 259 (BTN_3) Properties: Testing ... (interrupt to exit) Event: time 1687334663.436476, type 1 (EV_KEY), code 259 (BTN_3), value 1 Event: time 1687334663.436476, -------------- SYN_REPORT ------------ Event: time 1687334663.948482, type 1 (EV_KEY), code 259 (BTN_3), value 0 Event: time 1687334663.948482, -------------- SYN_REPORT ------------ Is there a way to tell the system that this is event is an acpi event or a driver would be needed? I don't think I can make a real driver but I think I could get read the event from /dev/input/by-path/platform-adc_keys-event with python or something. If I can't I could always wrap evtest and make it do the reading. Thanks!
-
Description This PR adds support for Recore A5, A6, and A7 hardware. Recore is a 3D printer control board based on Allwinner A64. Since the board uses the AR100 for real time stepping, the SCP is disabled and instead a version of Klipper is loaded instead. How Has This Been Tested? The patches have been tested by building the current and legacy kernels with the minimal images. [ ] Minimal image with current kernel [ ] Minimal image with legacy kernel Checklist: [ ] 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 [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
-
Okay, I figured out what happens 🙂. First I would like to correct myself: the measured (idle) voltage of 1.15V was actually 1.115V. This is good. When powered down, I double-checked all regulators again and was surprised that even the SY8113 is still on, but showed a bit more than 1.3V! For some reason I must have made a mistake when measuring before as this is consistent now. Even when booting, the SY8113 shows 1.3V initially and then drops to 1.115V after a while with occasionally switching between 1.3V and 1.115V later on depending on the load. So, I did take another more detailed look at the schematics and indeed Sinovoip implemented a poor man's PMIC for the 1.1V CPUX power supply that switches between these two voltages depending on the load and the CPU clock frequency. The signal is CPUX-SET. I guess this is known as the Linux kernel seems to switch between these two voltages. Now, I'm still interested in low power consumption after poweroff. So far, the board uses more power after executing poweroff compared to running idle on Linux (~0.7-0.8W vs. ~0.5W). The reason is that all regulators keep being enabled plus the SY8113 remains to be configured for 1.3V. I'm aware of the AR100 (CPUS) and also the crust firmware on GitHub. Obviously, the hardware implements that all but one (the 3.3V) regulator can be disabled, but so far that doesn't seem to happen. How can I help here? Should I look at and modify the crust firmware, i.e. add waiting to receive a "poweroff" trigger message from the kernel and set the appropriate GPIOs accordingly? The schematic tells me that CPUS is powered by RTC_VIO (via VDD_RTC via VCC-3V3). VCC-3V3 is the only regulator which can't be turned off. So, that's in principle okay as CPUS can still monitor POWER-KEY and restart the whole system. Best, Stephan
-
Orange Pi PC Plus power consumption increasing when halted [2]
Igor replied to kentAVR's topic in Allwinner sunxi
Researching background? If you want to run closed source proprietary Linux, use Xunlong / vendor stuff. If you want to use quality and open source, well, there is a looooong way. https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one but can't do many other things. Its always a trade. Providing "Armbian wallpaper" on top of Xunlong proprietary software would be dirt cheap. This particular feature is not supported yet for many reasons. You can read articles on the topic https://linux-sunxi.org/AR100 and there are many forum topics on this https://forum.armbian.com/search/?q=AR100&quick=1 Working features have nothing to do with a support status. https://docs.armbian.com/#what-is-supported We annually invest thousands of hours just into stabilising release builds vs. nothing that rolling distros do (arch - manjaro). If you need that certain feature works, pay for development to anyone you prefer. Once done, send a patch to us, we will integrate it at our cost and will maintain it if not too expensive. But you can also send it directly to kernel.org.
