StuxNet

  • Content Count

    106
  • Joined

  • Last visited

Reputation Activity

  1. Like
    StuxNet reacted to martinayotte in How to use the SPI flash on OPi Zero v1.4?   
    How do you use "dd" for that ?
    You can not use "dd" directly with /dev/spidevX-X, since it doesn't handle SPIFlash commands ...
    Either you use "flashrom" utility to write whole image or use python pyspiflash library and manage sector/page erase/read/write yourself.
    Don't expect been able to use it as filesystem, first because MTD partition kernel driver is probably not in Legacy builds, and second because those SPIFlash are pretty small.
    Those SPIFlash are ususally present to place U-Boot bootloader to allow booting from other devices such USB Storage or Network share.
     
  2. Like
    StuxNet reacted to chwe in Need help for Orange Pi Zero OS Installation   
    Armbian server image is ~1.5GB, since the smallest reliable SD-Cards for SBCs are 8GB. But it confuses me that you bought a SBC without HDMI for gui programs (Lazarus). So, did you buy the OPi Zero or the OPi Zero Plus2? If it is the original OPi Zero this might be a bad decision for your use case: no HDMI and a questionable wifi (XR819). You might think about a OPi One/Lite/Pc/PcPlus (3 UART on Pinheader, without using the seperated debug UART)?
  3. Like
    StuxNet got a reaction from MitchD in Need help for Orange Pi Zero OS Installation   
    Ummm?... because Q4OS only supports Pinebook, Pine64 and Raspberry Pi as per their downloads page. Unless I'm missing something. Even if I am, that would mean their "ARM port" download is trying to do something similar to Armbian by being compatible with multiple devices. Aside from chromebooks, tablets, etc... I think you'd be hard pressed to find an argument for using Q4OS over Armbian especially for OPiZero. Maybe that's just me though.
     
    https://q4os.org/downloads1.html

    So what's your reasoning as to why you opt for Q4OS over Armbian?
  4. Like
    StuxNet reacted to chwe in Connecting USB to Serial(TTl) (UART) adapter CH340G on Orange Pi Zero with Armbian( Legacy Kernel)   
    Do I understand you right? Your CHG340 is connected to your computer, thats were your COM3 comes from, so it might be a Windows machine and you try to connect with this serial to usb adapter to get access to your orange pi zero? Baud Rate is correctly? Should be 115200. You use the 3 pin header to get access? (ground, RX & TX @ 3.3V). 
     
    RX -->TX and TX-->RX connected?
    My CHG 340 changes sometime COM address on windows machine (don't know why) just to make sure you don't 'ride a dead horse'..  
  5. Like
    StuxNet reacted to richardk in What are you using your Orange Pi Zero for?   
    For my daughter: Generating sounds in a "Ghostbusters" proton pack, two of them in fact.     A Python script reads /dev/ttyS2 to receive instructions from an Arduino connected to buttons/switches, and mixes/plays powerup, powerdown, idle,  and fire sound effects.
     
  6. Like
    StuxNet reacted to MitchD in Buildroot realtime image for nanopi neo   
    It looks like your patches applied correctly, comparing your images to my make menuconfig shows its the same. I'm not sure why you're not getting ethernet. Once your board boots up, if you type "ifup eth0" it should come up. Also check the /etc/network/interfaces file to make sure eth0 is define, like this:
     
    auto eth0
    iface eth0 inet dhcp
           wait-delay 15
     
    I tested my mainline image on an orangepi zero and it booted right away with ethernet, so I'm not sure what is wrong. If you change out your SD card and power supply or USB cable you may have luck.
     
     
  7. Like
    StuxNet reacted to Igor in Upgrade kernel fails   
    This most likely means that your SD card is no longer with us.
  8. Like
    StuxNet got a reaction from pfeerick in Forgotten password   
    Replace friend with customer and you've lived my life. Good to know you figured it out. Take care.
  9. Like
    StuxNet reacted to TonyMac32 in 4k Output on the Tinkerboard?   
    The FAQ is totally incorrect, it is actually true 4K.  Their initial release used a "fake" 4k where it was up-scaled, why, honestly I don't know.  Now, the Legacy kernel works with 4k on my Samsung, however I am aware that some Acer products are... different.  I believe I saw a patch related to this, I can take a look.  The Next and Dev kernels do not yet have 4k support, I haven't rounded up everything needed, and the DRM system has gone through some changes since 4.4, so it's not a drop it in and go situation.
     
    their 4k video player is the QT based one found in the rockchip repo.
     
    @chwe I understand, I was actually outdoors repairing some masonry, I had to rebuild/replace some sections of a 70 year old wall.  Beautiful weather for it, and a good excuse to work with my hands.
     
  10. Like
    StuxNet reacted to chwe in 4k Output on the Tinkerboard?   
    According to their faq it's scalled to 4k from 1080P.
    Whenever the GPU is able to hardware decode 4K, doesn't mean that the software is able to do it... 
     
    IMO, don't think about 4K as long as your tinker runs not smoothly & stable with provided tinker OS.
    From TinkerOS 1.9:
    Seems that they still work on a stable 4K player.
     
    From the armbian dowloadpage:
    And a must read too. The tinker is a cool board from specs, but has some hardware fails. It's claimed to be a RPi with much more power, but on software side it's still WIP. 
    Just have a look on the open issues in the Rockchip subforum here (mine is lying around until I find motivation to play more with it. Sorry @TonyMac32 weather was too good and I was sailing during weekend ).
  11. Like
    StuxNet reacted to Igor in Marvell based 4 ports mPCI SATA 3.0   
    Clearfog PRO with Linux 4.12.4-mvebu Samsung 840 PRO utilization:
    iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 62501 101691 98761 94430 34522 93050 102400 16 183325 215091 231439 232948 101667 171875 102400 512 301985 307789 341261 344567 328849 309560 102400 1024 294818 309177 345099 347791 339763 309775 102400 16384 271066 344426 384226 388587 387169 346825 2 x Samsung 840 PRO in RAID0, ext4 utilization:
    random random kB reclen write rewrite read reread read write 102400 4 67614 95508 94561 94984 32561 74157 102400 16 174075 200947 222430 223840 109654 199578 102400 512 307905 294689 317652 308007 307057 268841 102400 1024 307821 317784 327007 330213 322851 317024 102400 16384 286193 383463 394221 398474 397951 374333  
    Logs: http://sprunge.us/CfRS 
    Controller temperature is stable at 64°C, network utilization is also at top speed.  Card was donated via Amazan wish list. Thank you!


     
    Hummingboard 2 with Linux 3.14.79-cubox (mainline not working out of the box)

    Not that impressive as Clearfog,  but works. 
    random random kB reclen write rewrite read reread read write 102400 4 28502 39271 37895 37983 22325 38821 102400 16 68494 80988 69940 70511 53264 80047 102400 512 116594 118132 93789 94280 92828 118884 102400 1024 138185 140277 122610 123717 120853 139393 102400 16384 183976 183169 151745 153813 151890 179652 Logs: http://sprunge.us/OeMY
     
    Espressobin
    2 x Samsung PRO 840, RAID 0, BTRFS
    http://sprunge.us/iBFS
    random random kB reclen write rewrite read reread read write 102400 4 21547 20493 37509 37024 21747 17728 102400 16 61955 56230 93068 93795 64349 45724 102400 512 188611 186828 175688 176961 172098 185109 102400 1024 215817 216559 189477 191846 188481 214727 102400 16384 226764 228502 229162 238883 222826 229894 Intel N4200 / Up2board Square
    1 x Samsung 840 PRO random random kB reclen write rewrite read reread read write 102400 4 65003 76031 93147 92507 32024 73029 102400 16 146880 175968 187734 224409 106025 163916 102400 512 244782 225736 348401 357949 343145 221037 102400 1024 239203 247778 313476 313372 309170 248540 102400 16384 254396 266530 357708 368483 370731 276458 2 x Samsung 840 PRO in RAID 0 random random kB reclen write rewrite read reread read write 102400 4 61680 70018 67650 66635 18221 67984 102400 16 145869 164784 147884 143877 46355 160169 102400 512 230140 219870 213069 199087 213587 210607 102400 1024 273150 271782 257206 279397 275632 271896 102400 16384 314895 311385 365117 376228 375081 317790 Native onboard SATA 1 x Samsung 840 PRO random random kB reclen write rewrite read reread read write 102400 4 70611 80842 100647 97276 30072 77666 102400 16 194707 208422 239401 224119 102211 218393 102400 512 346735 410867 401536 425167 396013 412711 102400 1024 374032 366490 378981 394321 382352 368195 102400 16384 441298 430380 475063 486540 482151 414518 Reference: A20's native SATA
     

    This document is work in progress ...
  12. Like
    StuxNet reacted to Mohammad Mubin in Tiny 3$ lcd on orange pi   
    sudo modprobe fbtft_device custom name=flexpfb speed=48000000 fps=60 gpios=reset:20,dc:1,wr:3,cs:10,db00:0,db01:14,db02:2,db03:21,db04:18,db05:19,db06:8,db07:9
    sudo modprobe flexfb width=320 height=480 buswidth=8 init=-1,0x11,-2,200,-1,0x36,-1,0x3A,0x05,-1,0x36,0x48,-1,0x13,-1,0x29,-1,0x2C,-3
    i edited the X11 config files to match it with the frame buffer and wrote startx
    i also tried displaying images but i get the same thing

  13. Like
    StuxNet reacted to Melanrz in Tiny 3$ lcd on orange pi   
    Tutorial for ili9325 and spfd5408

     
    soon tutorial for fastes ili9341

  14. Like
    StuxNet reacted to martinayotte in Problem with UART on Orange PI Zero   
    The way you are reading the serial port is ugly since you try to read(1000) without even checking if there is something to read, and yes 0.1ms is waste of time, especially if serial is empty, you should make it longer.
    You should is serial.inWaiting() > 0 to check if at least one char has come in...
     
  15. Like
    StuxNet reacted to chwe in New OPi Zero - Yet another high temperature issue...   
    Do you ever thought about alternatives (Maybe C.H.I.P or Omega 2 are better for battery powered IoT devices. This is a little bit out of my knowledge, not sure if these two are good proposals)? From my experience, the opi 0 is a little bit bitchy as soon as it runs into a undervoltage situation. I realized that the SoC (OPi 0, rev. 1.4) gets really hot (finger test) as soon as there's not enough power to start up the board. I'll investigate this as soon as I have more time and my second OPi 0 arrives (I would be annoyed, if I grill the only one which I have at the moment). 
  16. Like
    StuxNet reacted to TonyMac32 in Authentication token manipulation error   
    Are you a child in the schoolyard looking for ways to taunt someone, or are you an adult?  I understand being frustrated with an issue, but your lack of basic manners is unacceptable.
     
    As far as FS corruption: Win32DiskImager causes it.  It is a tool that is only used out of ignorance of superior options like Etcher.  Because of that, we do not support its use and automatically recommend the use of Etcher before we spend our time debugging issues that may simply be faulty SD card burning.  
     
    Other common problems: garbage/counterfeit SD cards, inadequate power supply, etc.  Read the documents you were given a link to.
  17. Like
    StuxNet reacted to tkaiser in Not able to connect via ssh on encrypted orange pi box   
    Since the original tutorial requires installing dropbear-initramfs package and to avoid conflicts with OpenSSH it is configured to run on another port.
  18. Like
    StuxNet reacted to martinayotte in Not able to connect via ssh on encrypted orange pi box   
    Although I didn't raad the whole thread and links, why are you trying to do ssh on port 2222 while standard port is 22 ?
  19. Like
    StuxNet reacted to MMGen in Full root filesystem encryption on an Armbian/Orange Pi PC 2 system   
    Update: commenting out the following line in 'boot.cmd' allows you to unlock the disk from the tty as well as via ssh:
    # if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=ttyS0,115200"; fi  
  20. Like
    StuxNet reacted to MMGen in Full root filesystem encryption on an Armbian/Orange Pi PC 2 system   
    Rechecked tutorial, fixed a non-critical error, removed a couple unnecessary commands.
     
    Just replace the bogus device filenames with real ones and everything will work "out of the box".
  21. Like
    StuxNet reacted to MMGen in Full root filesystem encryption on an Armbian/Orange Pi PC 2 system   
    Full root filesystem encryption on an Armbian/Orange Pi PC 2 system
     
    MMGen (https://github.com/mmgen)
     
    WARNING: This tutorial has been obsoleted by Full root filesystem encryption on an Armbian system. In addition, an automated script is available, which can be downloaded here or by cloning the following repository: git clone https://github.com/mmgen/mmgen-geek-tools
     
    This tutorial provides detailed, step-by-step instructions for setting up full root filesystem encryption on an Armbian/Orange Pi PC2 system. With minor changes, it can be adapted to other Armbian-supported boards. The disk is unlocked remotely via ssh, permitting unattended bootup.
     
    Requirements:
    Linux host system One Orange Pi PC 2 Two blank Micro-SD cards (or a working Armbian system for your board + one blank SD card) USB Micro-SD card reader Ability to edit text files and do simple administrative tasks on the Linux command line  
     
    Part 1 - Get, unpack and copy an Armbian image for your board
     
    Create your build directory:
    $ mkdir armbenc-build && cd armbenc-build Download and unpack an Armbian image for your board and place it in this directory.
     
    If you have two blank SD cards, the first will hold an ordinary unencrypted Armbian system used for the setup process, while the second will hold the target encrypted system.
     
    Alternatively, if you already have a working Armbian system for your board, you can use it for the setup process. In that case, your one blank SD card will be considered the “second” card, and you can ignore all instructions hereafter pertaining to the first card.
     
    Note that for the remainder of this section, the first SD card will be referred to as '/dev/sdX' and the second as '/dev/sdY'. You'll replace these with the SD cards' true device filenames. The device names can be discovered using the command 'dmesg' or 'lsblk'. If you remove the first card before inserting the second, it's possible (but not guaranteed) that the cards will have the same device name.
     
    Insert the first blank SD card and copy the image to it:
    $ sudo dd if=$(echo *.img) of=/dev/sdX bs=4M After the command exits, you may remove the first card.
     
    Now insert the second SD card, which will hold a small unencrypted boot partition plus your encrypted Armbian system. Copy the image's boot loader to it:
    $ sudo dd if=$(echo *.img) of=/dev/sdY bs=512 count=32768 Now partition the card:
    $ sudo fdisk /dev/sdY Within fdisk, create a new DOS disklabel with the 'o' command. Use the 'n' command to create a primary partition of size +200M beginning at sector 32768. Type 'p' to view the partition table. Note the end sector. Now create a second primary partition beginning one sector after the first partition's end sector and filling the remainder of the card. When you're finished, your partition table will look something like this:
    Device Boot Start End Sectors Size Id Type /dev/sdY1 32768 442367 409600 200M 83 Linux /dev/sdY2 442368 123596799 123154432 58.7G 83 Linux Double-check that the second partition begins one sector after the end of the first one. If you mess something up, use 'd' to delete partitions or 'q' to exit fdisk and try again.
     
    Once everything looks correct, type 'w' to write the partition table.
     
    Now you'll begin the process of copying the system to the second card. First you'll associate the image file with a loop device and mount the device:
    $ losetup -f # displays the name of the loop device; remember this $ sudo losetup -Pf *.img # associate image file with the above loop device $ mkdir mnt boot root $ sudo mount /dev/loopXp1 mnt # replace '/dev/loopX' with the above loop device Create a filesystem on the SD card's boot partition and copy the boot partition data from the image file to it:
    $ sudo mkfs.ext4 /dev/sdY1 $ sudo e2label /dev/sdY1 OPI_PC2_BOOT # don't omit this step! $ sudo mount /dev/sdY1 boot $ sudo cp -av mnt/boot/* boot $ (cd boot; sudo ln -s . boot) Create the encrypted root partition (for this the 'cryptsetup-bin' package must be installed on the host). You'll be prompted for a passphrase. It's recommended to choose an easy one like 'abc' for now. The passphrase can easily be changed later (consult the 'cryptsetup' man page for details):
    $ sudo cryptsetup --pbkdf argon2i --pbkdf-memory 600000 luksFormat /dev/sdY2 Note that the --pbkdf-memory argument must be less than the available free memory in kilobytes at bootup time.  Otherwise you’ll get an out-of-memory error and your disk will fail to unlock.  600000 is a safe value for the Orange Pi PC2 with its 1GB of RAM.
     
    Activate the encrypted root partition, create a filesystem on it and mount it:
    $ sudo cryptsetup luksOpen /dev/sdY2 foo # enter your passphrase from above $ sudo mkfs.ext4 /dev/mapper/foo $ sudo mount /dev/mapper/foo root Copy the system to the encrypted root partition:
    $ (cd mnt && sudo rsync -av --exclude=boot * ../root) $ sync # be patient, this could take a while $ sudo mkdir root/boot $ sudo touch root/root/.no_rootfs_resize Unmount the mounted image and second SD card, and free the loop device and encrypted mapping:
    $ sudo umount mnt boot root $ sudo losetup -d /dev/loopX $ sudo cryptsetup luksClose foo From here on, all your work will be done on the Orange Pi.
     
     
    Part 2 - boot into the unencrypted Armbian system
     
    If applicable, insert the first (unencrypted) SD card into the Pi's Micro-SD card slot.
     
    Insert a USB card reader holding the second SD card into a USB port on the Pi.
     
    Boot the Pi.
     
    If applicable, log in as root with password '1234', follow the password update instructions, and stay logged in as root. The following steps will be performed from a root shell.
     
     
    Part 3 - set up the unencrypted Armbian system
     
    Update the APT package index and install cryptsetup:
    # apt-get update # apt-get install cryptsetup  
     
    Part 4 - set up the encrypted Armbian system
     
     Prepare the encrypted system chroot:
    # BOOT_PART=($(lsblk -l -o NAME,LABEL | grep OPI_PC2_BOOT)) # ROOT_PART=${BOOT_PART%1}2 # cryptsetup luksOpen /dev/$ROOT_PART foo # mkdir /mnt/enc_root # mount /dev/mapper/foo /mnt/enc_root # mount /dev/$BOOT_PART /mnt/enc_root/boot # cd /mnt/enc_root # mount -o rbind /dev dev # mount -t proc proc proc # mount -t sysfs sys sys Copy some key files so you'll have a working Internet connection within the chroot:
    # cat /etc/resolv.conf > etc/resolv.conf # cat /etc/hosts > etc/hosts Now chroot into the encrypted system. From this point on, all work will be done inside the chroot:
    # chroot . # apt-get update # echo 'export CRYPTSETUP=y' > /etc/initramfs-tools/conf.d/cryptsetup # apt-get install cryptsetup-initramfs dropbear-initramfs # for focal and buster # apt-get install cryptsetup dropbear-initramfs # for bionic Check to see that the cryptsetup scripts are present in the initramfs (command should produce output):
    # gunzip -c /boot/initrd.img* | cpio --quiet -t | grep cryptsetup Edit '/etc/fstab' to look exactly like this:
    /dev/mapper/rootfs / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 /dev/mmcblk0p1 /boot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2 tmpfs /tmp tmpfs defaults,nosuid 0 0 Add the following lines to '/etc/initramfs-tools/initramfs.conf'. If the Orange Pi's IP address will be statically configured, substitute the correct static IP address after 'IP='. If it will be configured via DHCP, omit the IP line entirely:
    DEVICE=eth0 IP=192.168.0.88:::255.255.255.0::eth0:off Add the following parameters to the quoted bootargs line in '/boot/boot.cmd'.  Note that the 'root' parameter replaces the existing one:
    root=/dev/mapper/rootfs cryptopts=source=/dev/mmcblk0p2,target=rootfs If you want to be able to unlock the disk from the virtual console (which you probably do) as well as via ssh, then comment out the following line:
    # if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=ttyS0,115200"; fi In case you're wondering, 'setenv console "display"' doesn't work. Don't ask me why.
     
    Compile the boot menu:
    # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Copy the SSH public key from the machine you'll be unlocking the disk from to the Armbian machine:
    # rsync yourusername@remote_machine:.ssh/id_*.pub /etc/dropbear-initramfs/authorized_keys If you'll be unlocking the disk from more than one host, then edit the authorized_keys file by hand and add the additional SSH public keys.
     
    Edit '/etc/dropbear-initramfs/config', adding the following lines:
    DROPBEAR_OPTIONS="-p 2222" DROPBEAR=y Reconfigure dropbear:
    # dpkg-reconfigure dropbear-initramfs Make sure everything was included in the initramfs (both commands should produce output):
    # gunzip -c /boot/initrd.img* | cpio --quiet -t | grep dropbear # gunzip -c /boot/initrd.img* | cpio --quiet -t | grep authorized_keys Your work is finished! Exit the chroot and shut down the Orange Pi:
    # exit # halt -p Swap the SD cards and restart the Pi. Unlock the disk by executing the following command on your remote machine. Substitute the Pi's correct static or DHCP-configured IP address for the one below. If necessary, also substitute the correct disk password in place of 'abc':
    $ ssh -p 2222 -x root@192.168.0.88 'echo -n abc > /lib/cryptsetup/passfifo' If you choose to unlock the disk from the tty, just enter your disk password and hit ENTER.
     
    If all went well, your root-filesystem encrypted Armbian system is now up and running!
  22. Like
    StuxNet reacted to zador.blood.stained in CAN BUS support orange pi zero   
    Yes, it is listed as "required", not "optional".
  23. Like
    StuxNet reacted to martinayotte in CAN BUS support orange pi zero   
    Leave the PA13 as SPI_CS, and choose any other free GPIO for the IRQ, could be the original PA7.
  24. Like
    StuxNet reacted to martinayotte in CAN BUS support orange pi zero   
    PA13 : single pin cannot be IRQ and SPI_CS at the same time ...
  25. Like
    StuxNet reacted to zador.blood.stained in CAN BUS support orange pi zero   
    On Zero SPI bus 0 is wired to the SPI flash pads (even if the flash itself it's not soldered), and SPI bus 1 is wired to the pin headers, so it should be
    target = <&spi1>; instead