tparys

  • Posts

    176
  • Joined

  • Last visited

Reputation Activity

  1. Like
    tparys got a reaction from Werner in Orange Pi Zero error during apt update   
    Offhand, probably not a great idea to mix and match Debian and Ubuntu repositories. You may want to reinstall with the Debian derived Armbian before continuing. There's a very good chance you'll end up with library versioning issues, unless you know what you're doing.
     
    That said, it looks like you put "stable/updates" instead of "stable-updates" in your /etc/apt/sources.list ...
     
  2. Like
    tparys got a reaction from Heisath in initramfs-tools not fully installed on Debian Stretch with Armbian Linux 4.19.56-mvebu64   
    EspressoBin is currently in CSC support, so best to submit bugs/questions in in Peer to Peer Support.
     
    Also need to submit armbianmonitor output. It seems dumb, but there's a lot of necessary information in there.
     
     
    However, in this case, it tells you exactly what died. You've somehow uninstalled busybox (directly or indirectly), and initramfs-tools can't work properly without it.
     
     
    Not advisable. The initramfs-tools package generates the initrd file for the kernel, which is generally a required part of the boot process. You'll want to get this fixed, and probably not reboot in the meantime until you do.
  3. Like
    tparys got a reaction from phosgene in Trouble with Armbian Build CRYPTROOT "Starting Kernel..."   
    https://forum.armbian.com/topic/18583-encrypted-image-no-prompt/?tab=comments#comment-126748
  4. Like
    tparys got a reaction from Myron in How do I turn on networking using bash commands if I've accidentally disabled networking within the GUI shell?   
    Took a quick look on my system doing that.
     
    Doing "systemctl status", I don't see any obvious services that were started or stopped.
     
    You might learn more reading up on the options in the NetworkManager command line tool:
     
    $ man nmcli  
    Or check with the XFCE guys over at https://forum.xfce.org/ what exactly that network widget does.
  5. Like
    tparys got a reaction from Myron in The LED1 and LED2 on the BanabaPi Pro. How do I get them to show MMC card usage and the watchdog heart beat?   
    Pssst ... If you cat the trigger file, it'll tell you the valid options, and which one is currently selected.
     
    tparys@laptop:~$ cat /sys/class/leds/input4\:\:capslock/trigger none usb-gadget usb-host rfkill-any rfkill-none kbd-scrolllock kbd-numlock [kbd-capslock] kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock ACAD-online BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid disk-activity disk-read disk-write ide-disk mtd nand-disk cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 panic mmc0 rfkill0 phy0rx phy0tx phy0assoc phy0radio rfkill1 audio-mute audio-micmute  
    I'd wager the correct trigger is "mmc0", unless there's a both a SD card and eMMC slot on that board?
  6. Like
    tparys got a reaction from Willy Moto in Creating a .dtb/.dts file from an unknown/unsupported android TV box   
    If it's a TV box, you might get better results in the TV box forum.
     
    But some systems have the DTB embedded in the kernel image. If you can get to a shell, you can dump it from a running system sorta like:
     
    dtc -I fs -o devicetree.dts /sys/firmware/devicetree/base  
    Keep in mind that there are periodic changes to the DT format over time, and some vendors put in nonstandard hacks. Keeping these DTB files current is a major issue for Armbian devs. If it's for an unsupported box, it'll almost certainly require changes for everything to work properly.
  7. Like
    tparys got a reaction from Werner in how to make the Ubutu Scripts useful in Armbian? / to make the fan of nanopi M4V2 SATA hat always running...   
    nanopim4v2 rc.local[3751]: /etc/rc.local: 16: echo: echo: I/O error  
    That's the script error, probably line 16. Not sure why it failed. I don't see anything obviously wrong.
     
    Depending, it's possible the kernel is still initializing the PWM device at the time it runs. You can add some print statements like "echo HERE" to you script to confirm where it dies. You can try to add a delay like a "sleep 30" at the start of the script, but that's just a guess. Not sure why you'd be getting an I/O error.
     
    It's also possible that there's some kernel version differences between the FriendlyElec build and Armbian's kernel, so that scripting might need some changes.
     
    For example, I had to do this to turn on the PWM fan on my M4V2 metal case. You may need to experiment a bit.
     
    echo 0 > /sys/class/pwm/pwmchip1/export echo normal > /sys/class/pwm/pwmchip1/pwm0/polarity echo 50000 > /sys/class/pwm/pwmchip1/pwm0/period echo 40000 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable  
     
    Edit: As a note, my M4V2 had pwm0 set as inverted by default. Your settings of 90% power could be interpreted as 10% instead, and may not be enough for the fan to spin.
  8. Like
    tparys got a reaction from gounthar in How would you implement a super precise clock with a board running Armbian?   
    For what it's worth, Microsemi sells lots of stuff designed by Jackson Labs Technologies, which might open up the market options.
     
    Also, if you're looking for accurate clocks you can disconnect and take indoors, the term you're looking for is GPS Holdover. Just fair warning that the more accurate the clock, the longer it might take with view of the sky before it hits full accuracy (though Microsemi won't advertise that). FYI, double oven temperature compensated oscillators can get better accuracy than the some commercial grade atomic clock options, but may take up to 3 days of warmup to get to full spec..
     
    But if you're going to procure a couple and take them inside, consider a battery backup to avoid the initial training time, and make sure they get lots of sunlight before you need them.
  9. Like
    tparys got a reaction from TRS-80 in How would you implement a super precise clock with a board running Armbian?   
    On a local network, NTP tends to have an offset/jitter of around 20-50 ms.
     
    Distributing PPS to all your computers (may require signal buffering / EMI shielding) should get it down to <10 ms.
     
    You can also consider Chrony w/ PTP support, but will require all your network switches to support it to get the best performance. I don't recall offhand if it requires driver/kernel support.
     
  10. Like
    tparys got a reaction from gounthar in How would you implement a super precise clock with a board running Armbian?   
    On a local network, NTP tends to have an offset/jitter of around 20-50 ms.
     
    Distributing PPS to all your computers (may require signal buffering / EMI shielding) should get it down to <10 ms.
     
    You can also consider Chrony w/ PTP support, but will require all your network switches to support it to get the best performance. I don't recall offhand if it requires driver/kernel support.
     
  11. Like
    tparys got a reaction from StickyPine in Encrypted image no prompt   
    When using an encrypted root, it needs to be unlocked and prepared for mount in the kernel initramfs. This part runs after u-boot, but before SystemD takes over. It also have slightly different rules on where kernel output goes, where it only goes to one "console", which is specified in the kernel arguments (visible after boot in /proc/cmdline).
     
    If memory serves, the last "console=" argument takes priority during initramfs (though its hazy sometimes and it might be the first). You may need to adjust the order of the kernel arguments to make your password prompt appear on VGA or serial console (whichever you expect).
     
    I don't have a rockpro64 to test with, but you should verify that it's not doing something silly like going to a serial port with a different baud rate than your uboot. FYI, RK3399's use an odd baud rate of 1.5 megabaud.
  12. Like
    tparys got a reaction from MastinZgZ in RS485 in NanoPi Neo Core   
    I've not tried this, but you might start looking at the 485 specific device tree bindings. If it's possible, you'll almost certainly need to write your own overlay.
     
    Also, USB to 485 adapters are only around ~$15 USD on amazon. Unless you need to to use an onboard UART, or want to do it as a project, it may not be worth the time investment.
  13. Like
    tparys got a reaction from chupo_cro in Configure static IP by editing config file in boot partition?   
    Perhaps look at /boot/armbian_first_run.txt.template ?
  14. Like
    tparys reacted to lanefu in How to make ESPRESSObin v7 stable?   
    Okay..  There's another open role that you may be interested in:

    We're looking for someone who's interested in the hardware, likes to post on the forum to discuss and share technical improvements, but also get angry about low participation, and take any opportunity available to insult the Armbian project and yell at developers and contributors who generally have good intentions.
     
    Is that something you'd be interested in taking on?
  15. Like
    tparys got a reaction from djurny in Unable to mount LUKS-encrypted disk   
    I think @lanefu was referring to doing a diff between the configs of the rockchip64 kernel which does not work, and the sunxi kernel which does.
     
    Based on the error, I'd wager the keyslot open is failing because you're missing a hash function. Believe the default is SHA1, unless you specified something different. Running "cryptsetup luksDump /dev/sda1" or whatever, should tell you for sure.
     
    If your system has AF_ALG compiled in, you can also run "cryptsetup benchmark", which runs typical hash and cipher algorithms used by LUKS. If it fails on something, that could be a clue.
  16. Like
    tparys got a reaction from TRS-80 in Managing cpufreq on big.LITTLE   
    Ever since I read through THIS POST a while back, I started digging through the cpufrequtils init script, and was a more or less disappointed with what I found. It's largely a product of the CPUs that were available around that time (eg - Pentium 3). Namely that all cores in the system are the same, and there's should be only one master policy that controls everything.
     
    Of course ARM big.LITTLE totally breaks these assumptions, and leaves the script with no viable way to specify different schedulers or frequency ranges for each CPU cluster. It still runs, but not really correctly. For example, you can't set the RK3399 little cores above 1.4 GHz, but that's basically what it attempts to do on every boot.
     
    Also it needs use "cpufreq-set" to do it's job, which seems too hard when the sysfs interface is already pretty simple. Really, that extra complexity isn't buying you a single thing. Maybe it made more sense 10-15 years ago.
     
    So I took a crack at doing a far simpler, stupid version of that script (on perhaps smarter depending on perspective). It can generate it's own config, and I think that it comes across much more readable and accessible.
     
    ### # CPUFreq policy for CPUs: 0 1 2 3 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY0_GOVERNOR=ondemand # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 POLICY0_MIN_FREQ=408000 POLICY0_MAX_FREQ=1416000 ### # CPUFreq policy for CPUs: 4 5 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY4_GOVERNOR=conservative # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 POLICY4_MIN_FREQ=408000 POLICY4_MAX_FREQ=1800000  
    And using it isn't too hard ...
     
    cp cpufrequtils-bl /etc/init.d/ sudo /etc/init.d/cpufrequtils-bl save sudo vi /etc/default/cpufrequtils-bl sudo systemctl disable cpufrequtils sudo systemctl enable cpufrequtils-bl  
    I know that this is probably pretty far down on the list of priorities, but does anyone thing that this would be useful to others?
     
    cpufrequtils-bl
  17. Like
    tparys got a reaction from lanefu in Managing cpufreq on big.LITTLE   
    Ever since I read through THIS POST a while back, I started digging through the cpufrequtils init script, and was a more or less disappointed with what I found. It's largely a product of the CPUs that were available around that time (eg - Pentium 3). Namely that all cores in the system are the same, and there's should be only one master policy that controls everything.
     
    Of course ARM big.LITTLE totally breaks these assumptions, and leaves the script with no viable way to specify different schedulers or frequency ranges for each CPU cluster. It still runs, but not really correctly. For example, you can't set the RK3399 little cores above 1.4 GHz, but that's basically what it attempts to do on every boot.
     
    Also it needs use "cpufreq-set" to do it's job, which seems too hard when the sysfs interface is already pretty simple. Really, that extra complexity isn't buying you a single thing. Maybe it made more sense 10-15 years ago.
     
    So I took a crack at doing a far simpler, stupid version of that script (on perhaps smarter depending on perspective). It can generate it's own config, and I think that it comes across much more readable and accessible.
     
    ### # CPUFreq policy for CPUs: 0 1 2 3 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY0_GOVERNOR=ondemand # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 POLICY0_MIN_FREQ=408000 POLICY0_MAX_FREQ=1416000 ### # CPUFreq policy for CPUs: 4 5 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY4_GOVERNOR=conservative # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 POLICY4_MIN_FREQ=408000 POLICY4_MAX_FREQ=1800000  
    And using it isn't too hard ...
     
    cp cpufrequtils-bl /etc/init.d/ sudo /etc/init.d/cpufrequtils-bl save sudo vi /etc/default/cpufrequtils-bl sudo systemctl disable cpufrequtils sudo systemctl enable cpufrequtils-bl  
    I know that this is probably pretty far down on the list of priorities, but does anyone thing that this would be useful to others?
     
    cpufrequtils-bl
  18. Like
    tparys got a reaction from lanefu in How to enanble standart Debian network configurotion?   
    ifupdown
  19. Like
    tparys got a reaction from TCB13 in [Invalid] - NanoPi M4V2: SPI Not Working   
    As entertaining as this thread is so far, I suggested to @TCB13 to post here to get more eyes on the problem.
     
    I can confirm that enabling the overlay in question didn't do the expected thing. And "armbianmonitor -u" is here: http://ix.io/3nS8
     
    Interestingly, the overlay seems to be disabling the spidev?
     
    fragment@4 { target = <0xffffffff>; __overlay__ { #address-cells = <0x01>; #size-cells = <0x00>; spidev { compatible = "spidev"; status = "disabled"; reg = <0x00>; spi-max-frequency = <0x989680>; }; }; };  
    Offhand, I'm not sure what's required to switch between multi-function pins, but figured there would be far more eyes on the problem here rather than Peer to Peer Support.
  20. Like
    tparys got a reaction from TCB13 in NanoPi M4V2: SPI - SSD1351 1.5 Inch RGB OLED Display   
    So the M4V2 is a supported board. that the SPI isn't working is probably worth a post by itself in the Rockchip 3399 Subforum.
     
    At a glance, I tried turning on the SPI on my M4V2 and didn't see any spidev devices pop up, but might need to pull out the serial console to see if u-boot is throwing any warnings about the overlay.
     
    Taking a look at the overlay, I'm not sure it looks correct, as it looks like even if it applies the SPI channel is disabled.
     
    fragment@4 { target = <0xffffffff>; __overlay__ { #address-cells = <0x01>; #size-cells = <0x00>; spidev { compatible = "spidev"; status = "disabled"; reg = <0x00>; spi-max-frequency = <0x989680>; }; }; };  
     
  21. Like
    tparys reacted to Werner in Plans for RISC-V boards like BeagleV, Nezha RISC-V SBC and Allwinner D1 SBC?   
    Which is true but barely anyone wants to step in and provide long-term maintenance....
  22. Like
    tparys got a reaction from TCB13 in NanoPi M4V2: Standard PCIe Devices Anyone?   
    Looks like a neat setup. I was not aware that M.2 to 5x SATA device existed.
     
    But before you reinvent the wheel, have you considered that you basically made a Helios64 without the nice enclosure?
  23. Like
    tparys got a reaction from sami in serial data with framing bits(Nanopi Neo Core)   
    https://www.go4b.com/usa/technical-support/product-manuals/t500-hotbus/rs485-wiring-guide.pdf
     
    485 uses differential pair as a both a send and a receive. Both pins are both input and output. There's not really an RX pin unless you convert back to 232.
     
    If you take a look at example link. You can have multiple listeners using 485 to 232 converters attached to that differential pair, and may do what you want.
  24. Like
    tparys got a reaction from TonyMac32 in Avnet MicroZed   
    https://drive.google.com/drive/folders/1YWMDbbx0p4dLPO3Mr3921vNay8l-_vHo?usp=sharing
     
    This is a topic to discuss CSC Armbian support on the Avnet MicroZed board, and adding a similarly supported SoC family for the Xilinx Zynq. In terms of "interesting boards", the Zynq is a combination ARM/FPGA SoC that pairs a dual core Cortex A9 @ 667 MHz with a Artix-7 family FPGA fabric. In terms of performance, the A9's are nothing to write home about, but the FPGA fabric opens some rather interesting possibilities for those determined enough to use them.
     
    For the unfamiliar, an FPGA (Field Programmable Gate Array) is a sort of reconfigurable logic. It allows one to have dynamic hardware components instead of static pieces selected by the board manufacturer. Want 100+ GPIO? Sure. A dozen serial ports? Alright. 37 I2C buses? You might need to share some interrupts, but I'm not aware of a specific reason that shouldn't work. Really, you're limited by pin count, FPGA fabric usage, and what you can express in Xilinx Vivado.
     
    Be aware, if editing Device Trees puts you off, this is not the board for you. You will need to do substantially more to get anything significant working. If you do not have a copy of Vivado installed, you will not get far. Interested users should start with Xilinx/Avnet documentation or HERE.
     
    Current development status:
    MicroZed (7020) booting up, appears to be working fine CPU Frequency Scaling (333 or 667 MHz ) FPGA bitstream loading (See below gotchas) Onboard Gigabit Ethernet USB (See below gotchas) GPIO, including board heartbeat LED Things that aren't working:
    DTB Overlays (seems to freeze board when enabled in u-boot config) PMOD connector (Didn't enable it in the Vivado, Design, FSBL, DTB, etc..) Current gotchas:
    Zynq u-boot doesn't work like other boards. u-boot and the Zynq FSBL (First Stage Bootloader) get baked together into a file called "boot.bin" via a Xilinx program called "bootgen". This is not currently in the image, so are not able to modify this file on-board. The MicroZed 7010 and 7020 are different boards. The CPU is compatible, but the 7020 has a larger FPGA and access to more pins (eg - Bank 13 on the MicroZed schematics) One of the jobs of the FSBL is to configure the Zynq MIO (Multipurpose I/O). To a limited extent, this re-configures which CPU pins go where on the PMOD connector, sets pull-up or pull-down resistors, and does other things. I think it's possible to skip the FSBL entirely and go directly to u-boot, but am unsure how that's supposed to work in a general sense. The Avnet preset for the MicroZed board specifies the correct reset pin for the USB PHY, but Vivado is not currently using/respecting it. If you make a new design, and do not check that the USB0 reset is enabled on MIO7, and build your own FSBL, the onboard USB port will not be usable.  
     
  25. Like
    tparys got a reaction from Heisath in I want to use the arduino board to detect the distance in three directions at once   
    Not that I have experience with these sensors, but looks like the general flow is this:
    hit the sensor with a pulse (low/high) count cycles until a response (pulseIn) As it's a microcontroller, pulseIn will probably not return until there is a response. The second call to pulseIn() probably starts counting after you're done printing the value from the first. Considering your output pulses happen within 2-10 ms of each other, I bet this happens:
     
    digitalWrite(center_Trig, LOW); digitalWrite(right_Trig, LOW); a=pulseIn(left_Echo, HIGH) / 58.00; Serial.println(a); // <- 2nd, 3rd echos arrive here b=pulseIn(center_Echo, HIGH) / 58.00; // <- timeout Serial.println(b); c=pulseIn(right_Echo, HIGH) / 58.00; // <- timeout Serial.println(c);  
    Maybe pulse the second sensor after you're done reading the return from the first? Then the third when the second is done?