lanefu

  • Posts

    1177
  • Joined

  • Last visited

Reputation Activity

  1. Like
    lanefu reacted to jimmij in We want YOU for armbian   
    Hi Werner, 
     
    I'm more of an enthusiast than IT guy, so my technical skills are limited. However, I can put together some good graphics, should you have a requirement for that. I can also put together picture mock-ups of t-shirts and mugs for your store.
     
    cheers,
     
    Jim
  2. Like
    lanefu reacted to Green Daddy in Boot from SSD using Hardkernel's Odroid HC4   
    Boot from SSD without SD card is currently not supported on HC4. However, it is easy to have only the boot loader on SD card (as @Werner stated above):
    - flash armbian image to SD Card
    - erase petitboot as stated above
    - boot armbian from SD Card
    - run nand-sata-install within armbian
    after this
    - only the boot loader rests on SD card (i.e. you need the SD card plugged in for it to be able to boot) - but no I/O on SD card after boot loader
    - OS root partition (and entire system) runs from SSD
    - any update updates boot loader and kernel where they actually reside - so no special precautions needed (despite the usual "update may break something")
     
    I am running on this setup and it works like a charm for me.
     
    Hope that helps
     
    Green Daddy
  3. Like
    lanefu reacted to Павел Мухатаев in Proof of concept - Realtek 1295   
    Hello
     
    I'm trying to run armbian (or any other custom linux) on my NAS TerraMaster F4-210/2G (SoC Realtek RTD1296 based). It has uart connector (the same connector and pins as Zidoo X9S).
    So I've created USB stick with Fat32, put uImage and device tree files into it, created another ext2 partition to use as root. Took uImage from banana-pi-w2 just to check things. And used the following command to load my kernel from uboot (there is no b2ndbc command in my uboot):
    Realtek> env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/sda1 rootfs=vfat Realtek> usb start && fatload usb 0:1 $kernel_loadaddr uimage && fatload usb 0:1 $fdt_loadaddr tm_f4-210.dtb && env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/sda2 rootfs=ext2 init=/bin/bash && bootr starting USB... ... reading uimage 10630032 bytes read in 403 ms (25.2 MiB/s) reading tm_f4-210.dtb 65536 bytes read in 30 ms (2.1 MiB/s) Start Boot Setup ... *** rtkspi_read32_md 422, tar 0x0b000000, src 0x881a0000, len 0x00050000 ... PowerOnOSD~~ [ 0.000000] psci: probing for conduit method from DT.  
    After that original kernel loaded instead of mine.
     
    Then I tried to use bootm - also without any luck
    Realtek> usb start && fatload usb 0:1 $kernel_loadaddr uimage && fatload usb 0:1 $fdt_loadaddr tm_f4-210.dtb && env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/sda2 rootfs=ext2 init=/bin/bash && bootm $kernel_loadaddr - $fdt_loadaddr Wrong Image Format for do_booti command ERROR: can't get kernel image!  
    I didn't find any documentation on bootr command which stays for `bootr   - boot realtek platform`. So my questions are:
    is it possible to get info from current stock uboot or devtree or kernel. Or what image type is required by bootm.
     
    uboot load log
    uboot help
    uboot base, bdinfo, flinfo, printenv, showvar, version
     
    Also in my device-tree I see the following:
    chosen { bootargs = "rdinit=/sbin/init mtdparts=RtkSFC:128k(factory),512k(uboot),320k(logo),1408k(afw),64k(dtb),7680k(kernel),5632k(initrd) earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 loglevel=7"; linux,initrd-start = <0x2200000>; linux,initrd-end = <0x2600000>; compatible = "Realtek,rtk1295-cma_info"; cma-region-enable = <0x01>; cma-region-info = <0x00 0x1000000 0x11000000>; }; memory { device_type = "memory"; reg = <0x00 0x80000000>; }; mem_remap { compatible = "Realtek,rtk1295-mem_remap"; #address-cells = <0x01>; #size-cells = <0x01>; ranges; rbus { reg = <0x98000000 0x200000>; }; common { reg = <0x1f000 0x1000>; }; ringbuf { reg = <0x1ffe000 0x4000>; }; };  
  4. Like
    lanefu got a reaction from gounthar in Armbian the Virtual Machine   
    Been dreaming of this one for a while.  Finally got a weekend to focus on it recently.  I'm hoping someone is eager to take what I've done and move It along some more.

    Here's what we have so far.

    * a linux 'family' called virtual.conf
    * a kernel config called linux-virtual-current.config
    * a board called virtual-qemu.wip
     
    The result is a full HVM accelerated armbian image with a kernel compiled with all the virtio drivers for disk, network and video.   Also a u-boot.bin made for qemu that can boot the image when used as the qemu bios/firmware
     
    I've ran it as a VM on ubuntu using plain qemu on a Ampere eMag box.. and using UTM (qemu) on Apple M1 in MacOS

    this is using u-boot, not uEFI.. and you need to copy the u-boot.bin manually from cache/sources/u-boot...../u-boot.bin and use it as your chosen bios for qemu.  I left some quick breadcrumbs on how to launch within the board config file.
     
    I want to keep the u-boot option, but obviously we need this to support uEFI booting to be viable for the masses.

    Next steps:

    * automatically resize and convert resulting image to qcow2 format
    * solve how to add cloud-init to image
    * solve for installing grubEFI for booting and whatever partition layout is needed
    * figure a proper way to write uboot to the image so thet qemu can boot without loading as a bios
    * strip extra hardware drivers out of kernel and make this thing lean

    PS Did I mention Desktop Works too?

     
     
     
  5. Like
    lanefu got a reaction from Werner in Patch Management Process   
    But.... this is a great topic where we need to start working on a process / protocol for patches like this
  6. Like
    lanefu reacted to hexdump in Armbian the Virtual Machine   
    @lanefu - as you mentioned the m1 mac: there is a very nice brew package around, which gives you a qemu there which even sends opengl via virgl and angle to the m1 gpu - not the fastest in the world, but better and more cpu saving than software rendering - https://github.com/knazarov/homebrew-qemu-virgl
  7. Like
    lanefu got a reaction from guidol in Armbian the Virtual Machine   
    Been dreaming of this one for a while.  Finally got a weekend to focus on it recently.  I'm hoping someone is eager to take what I've done and move It along some more.

    Here's what we have so far.

    * a linux 'family' called virtual.conf
    * a kernel config called linux-virtual-current.config
    * a board called virtual-qemu.wip
     
    The result is a full HVM accelerated armbian image with a kernel compiled with all the virtio drivers for disk, network and video.   Also a u-boot.bin made for qemu that can boot the image when used as the qemu bios/firmware
     
    I've ran it as a VM on ubuntu using plain qemu on a Ampere eMag box.. and using UTM (qemu) on Apple M1 in MacOS

    this is using u-boot, not uEFI.. and you need to copy the u-boot.bin manually from cache/sources/u-boot...../u-boot.bin and use it as your chosen bios for qemu.  I left some quick breadcrumbs on how to launch within the board config file.
     
    I want to keep the u-boot option, but obviously we need this to support uEFI booting to be viable for the masses.

    Next steps:

    * automatically resize and convert resulting image to qcow2 format
    * solve how to add cloud-init to image
    * solve for installing grubEFI for booting and whatever partition layout is needed
    * figure a proper way to write uboot to the image so thet qemu can boot without loading as a bios
    * strip extra hardware drivers out of kernel and make this thing lean

    PS Did I mention Desktop Works too?

     
     
     
  8. Like
    lanefu got a reaction from jeanrhum in Armbian the Virtual Machine   
    Been dreaming of this one for a while.  Finally got a weekend to focus on it recently.  I'm hoping someone is eager to take what I've done and move It along some more.

    Here's what we have so far.

    * a linux 'family' called virtual.conf
    * a kernel config called linux-virtual-current.config
    * a board called virtual-qemu.wip
     
    The result is a full HVM accelerated armbian image with a kernel compiled with all the virtio drivers for disk, network and video.   Also a u-boot.bin made for qemu that can boot the image when used as the qemu bios/firmware
     
    I've ran it as a VM on ubuntu using plain qemu on a Ampere eMag box.. and using UTM (qemu) on Apple M1 in MacOS

    this is using u-boot, not uEFI.. and you need to copy the u-boot.bin manually from cache/sources/u-boot...../u-boot.bin and use it as your chosen bios for qemu.  I left some quick breadcrumbs on how to launch within the board config file.
     
    I want to keep the u-boot option, but obviously we need this to support uEFI booting to be viable for the masses.

    Next steps:

    * automatically resize and convert resulting image to qcow2 format
    * solve how to add cloud-init to image
    * solve for installing grubEFI for booting and whatever partition layout is needed
    * figure a proper way to write uboot to the image so thet qemu can boot without loading as a bios
    * strip extra hardware drivers out of kernel and make this thing lean

    PS Did I mention Desktop Works too?

     
     
     
  9. Like
    lanefu got a reaction from Werner in Armbian the Virtual Machine   
    Been dreaming of this one for a while.  Finally got a weekend to focus on it recently.  I'm hoping someone is eager to take what I've done and move It along some more.

    Here's what we have so far.

    * a linux 'family' called virtual.conf
    * a kernel config called linux-virtual-current.config
    * a board called virtual-qemu.wip
     
    The result is a full HVM accelerated armbian image with a kernel compiled with all the virtio drivers for disk, network and video.   Also a u-boot.bin made for qemu that can boot the image when used as the qemu bios/firmware
     
    I've ran it as a VM on ubuntu using plain qemu on a Ampere eMag box.. and using UTM (qemu) on Apple M1 in MacOS

    this is using u-boot, not uEFI.. and you need to copy the u-boot.bin manually from cache/sources/u-boot...../u-boot.bin and use it as your chosen bios for qemu.  I left some quick breadcrumbs on how to launch within the board config file.
     
    I want to keep the u-boot option, but obviously we need this to support uEFI booting to be viable for the masses.

    Next steps:

    * automatically resize and convert resulting image to qcow2 format
    * solve how to add cloud-init to image
    * solve for installing grubEFI for booting and whatever partition layout is needed
    * figure a proper way to write uboot to the image so thet qemu can boot without loading as a bios
    * strip extra hardware drivers out of kernel and make this thing lean

    PS Did I mention Desktop Works too?

     
     
     
  10. Like
    lanefu reacted to going in creating packages in the armbian build system   
    For the sake of experiment, we will try to disable the creation of the kernel header module in the configuration for 5.12.
    I have run out of ideas. Tomorrow I will make the scripts easier, as in the 5.4 kernel.
    As just shown @Cornelius
  11. Like
    lanefu reacted to tony013 in my ordeal with rockpi4 and Penta Sata Hat + Tower   
    I had bought the kit because I got attracted by its compact size. I had problems with my old media pc so good opportunity to tackle something new.
    I thought, my requirements for a media server would be quite low/easy to fulfill:
    smooth playback of 1080p movies clean multichannel sound access to firefox  
    After testing all avaliable images on the rockpi, it was clear, that actually only LE offers exciting movie enjoyment. I had to realize, that my ideas are quite demanding after all.
    So it was clear, I had to get the driver from radxa working on LE.
     
    Why?
    well, hardware design of rockpi4 with extension HATs is somehow stupid. The flat cable needs to go from plugged board below systemboard to HAT above system board, so sdcard could not be changed any more.

     
    and as shown here:
     
     
    sd-card cannot be used together with the tower. Only emmc-support for boot. But emmc module is not exchangeable.
    That is why I had to start this odyssey.
     
    I tested the driver with officially supported images:
    on debian (linaro) the driver could be installed and the fan runs. Neither button nor display works. on ubuntu driver install scripts tells, that nothing has to be done, but nothing works ootb. No fan, no button, no display on armbian or LE the install script reffers to the git archive.  
    I started with self compiled LE, but I'm not skilled to port lowlevel libraries to unknown system. Quite hard going
     
    Then I discovered posting of PetrozPL and JackR. Both scripts worked on armbian - well, I had some problems, getting into it, but ...
    anyway: trying the scripts on LE showed - no way. LE has no bash and busybox does not support arrays ...
     
    So I researched, how I could drive the fan using only tools avaliable at LE. Unfortunately LE has no reasonable interpreter for scripting. Only python :(
    I never wrote a line in python before!
     
    I first had to check, whether the kernel of LE supports fan control. LE has no dtb-overlay support for rockpi. So had to change dtb manually like this:
    copy dtb-file to writable location decompile with dtc -I dtb -O dts -o rk3399-rock-pi-4a.dtb rk3399-rock-pi-4a.dts find sections named pwm@ff420000 and pwm@ff420010 change status "disabled" into status = "okay" recompile dts with dtc -O dtb -o rk3399-rock-pi-4a.dtb -b O -@ rk3399-rock-pi-4a.dts copy dtb file back to original location (/flash)  
    After reboot, fan works as with armbian - so I could write my fan-driver. Now system was ready to assemble the tower.
    I tested the driver with all other test images. Had to change code to work with older python releases and had some troubles with the button. But now driver runs stable and - as far as I can judge so far, where my driver does not run, other drivers will fail too.
     
    Well, my work with LE had the background, that I could get multiboot into play. But that seems pretty impossible.
    So I startet again researching, what could fulfill my ideas.
    Multimedia legacy - kodi works, movies are enjoyable. But no button support armbian current - no kodi, vlc works fine. Fan control works with button support debian/ubuntu - Fancontrol works with button support, but video playback is disgusting twisterOS - kodi works, movies are enjoyable, but no fan, no button  
    I like twisterOS and the gimmick with the circles, but the text was unreadable for me. So I tweaked the gimmick and now I have it usable on my desktop as well on plain armbian. Using armbian instead of twisterOS has the benefit, that I don't have to flood the boot media with rubbish I never use (like openoffice and all that gaming stuff)
     
    Actually my armbian current looks like this:

     
    or a bit busy with firefox:
     
    So the open jobs (next steps) are:
    get multiboot into play (then I could use LE together with armbian) get another kernel on twisteros, that supports pwm - then I could use twisteros get a recent kodi on current armbian, then I could forget about all others  
  12. Like
    lanefu got a reaction from Werner in Plans for RISC-V boards like BeagleV, Nezha RISC-V SBC and Allwinner D1 SBC?   
    FYI your donation IS greatly appreciated. 
     
     I don't want the context of this conversation to convey the contrary. 
  13. Like
    lanefu reacted to tony013 in NFS protocol not supported?   
    Ok, I created my first pull-request with a network section in troubleshooting guide.
     
    With Jira - I don't know, seems not to work. I read, that communication about a topic should happen in Jira, so I created an account. But probably you have to grant me some permissions to enable participating ...
     
    So how should I start with Jira topics? For example, AR-735 is a topic, that sounds interesting. I use that pwm overlay on armbian as well as patches at LE ...
    What needs to be done?
     
    by the way: we're quite off topic already. Where's the right place for this kind of questions?
  14. Like
    lanefu reacted to Werner in IRC channels moved to Libera.chat   
    tl;dr: connect to irc.libera.chat and join #armbian
    ---------------------------------------------------------------
     
    Due to the weird stuff happening on Freenode we decided to move our channels to the recently founded Libera.chat network.
     
    The announcement thread in forums as well as our documentation have been updated accordingly.
    To make transition more comfortable a relay bot has been put in place to sync messages between the #armbian channel on both Freenode and Libera.
     
    For those who had project affiliation cloaks please drop me a message to get them reassigned. Be sure to have your nick registered with Nickserv beforehand.
     
    For more information about what happened use your favorite search engine or reddit and look for stuff like "freenode hostile takeover" or similar.
  15. Like
    lanefu reacted to Igor in very confused --> /etc/NetworkManager/dispatcher.d/80-update-htop-and-offload-tx   
    Thanks @tkaiser 
     
    I'll roll out update later on.
  16. Like
    lanefu reacted to Werner in very confused --> /etc/NetworkManager/dispatcher.d/80-update-htop-and-offload-tx   
    https://github.com/armbian/build/commit/f0f10a5b68aff3c766f2e8790ac4ce9f3c3e2160
  17. Like
    lanefu reacted to sgjava in Security cameras   
    OK, so I have things dialed in a bit better now. FFMPEG seems to like TCP over UDP for these streams. I'm seeing a lot less artifacts in the videos. Below is 12 hours of network and CPU activity for 3 4K cams at 12.5 FPS and 1 4K cam at 15 FPS (four 4K cams total) at highest quality. CPU seems to max out around 10% per camera and network maxes out around 45 mb total. I'm using a 1G PoE switch, so the bandwidth will never be an issue. The question then becomes how much more real-time processing can I do. CV routines are typically expensive even though I've learned tricks using ROI (region of interest). This isn't as much of a problem with a single camera, but I'm planning on six cameras. Obviously the most important thing for me now is to capture motion videos.
     
    Once the bread and butter stuff is done then I can look at adding various detection code (besides motion). The question becomes do I want real-time detection or perhaps offload that to another SBC. The fact that I can record this many 4K cameras with an Odroid XU4 is pretty amazing. Look at Blue Iris requirements https://ipcamtalk.com/wiki/choosing-hardware-for-blue-iris/ and this really doesn't cover electrical costs and heat dissipation. I'm working on a Pine 64 today with USB cam, so I'll test single camera encoding. Basically the code will scale to many cameras or a single camera.


     

  18. Like
    lanefu reacted to Superkoning in Plans for RISC-V boards like BeagleV, Nezha RISC-V SBC and Allwinner D1 SBC?   
    FWIW: I'm an Armbian user, and, yes, I've done a few donations in the past.
  19. Like
    lanefu reacted to Igor in very confused --> /etc/NetworkManager/dispatcher.d/80-update-htop-and-offload-tx   
    Current implementation was reported to have security issues:
    https://github.com/stealth/7350topless
    Any ideas how to do it properly without losing functionality and without much of rework?
  20. Like
    lanefu reacted to unknown in RK3399 RAM overclocking rockpro64   
    @Salvador Liébana:
     
    Please don't use 1.5 Volts. You will destroy your Rockpro64! If your CPU can't handle 2.2GHz at 1.3 Volt then it can't handle it at all. 1.5 Volts is .25 Volts above the RK3399 specifications. 1.5 Volt will not only wear your CPU much more than needed it will also make the system unstable. Run 'stress -c 6' and you will see.
  21. Like
    lanefu reacted to ning in #armbian IRC channel linked to Libera.chat   
    I really don't understand this kind of things, it looks like not moving to libera.chat is something sin.
     
    freenode atm sure it in difficult, they are splited, is it necessary to stand oneside, before everything clear and settle down?
     
     just like openoffice. after many years virtualbox is still running very good.
  22. Like
    lanefu reacted to Miro-Sk in Logrotate service configuration (/etc/systemd/system/logrotate.service)   
    Hello, 
    I registered that after upgrading to Armbian 21.05.1 the behaviour of /usr/sbin/logrotate /etc/logrotate.conf was changed.
    Currently, step "3) ExecStart = /usr/sbin/logrotate /etc/logrotate.conf" is performed in the /var/log.hdd/ directory (in the previous version this step was performed in the /var/log directory).
     
    So after the upgrade, I changed:
    1) in /etc/logrotate.d/rsyslog:
    /var/log.hdd/syslog -> /var/log/syslog
    2) in the /etc/systemd/system/logrotate.service [Service] section as follows:
    [Service]
    Type = oneshot
    ExecStart = / usr / sbin / logrotate /etc/logrotate.conf
    ExecStartPost = / usr / lib / armbian / armbian-ramlog write
     
    After these changes logrotate works according to my expectations again.
  23. Like
    lanefu reacted to sgjava in Security cameras   
    So I have two 4K @ 12 FPS cameras that stream to a buffer file. Currently I'm only doing motion detection, but that drives everything else obviously detection wise. On an Odroid XU4 each camera uses only 10%. Motion videos are just copied from the buffer file. I'm using H265+ without any transcoding. So far so good. Not quite ready to post up to github yet though. I doubt you get better CPU utilization than this. I'm using the substream at 4 FPS 640x480 for motion detection.

    One other thing to note is I proxy mjpeg and h265+ streams, so for cameras that only allow one stream you can have security software running and still stream live. I'm using PoE cameras and will have six 4K cameras running soon. So in essence you can build a cheap NVR without the hardware requirements of Blue Iris etal or just build a single smart camera. Armbian allows hardware encoding with ffmpeg on some models, so you can even encode USB cams with low overhead.
  24. Like
    lanefu reacted to Igor in Don't install log2ram by default   
    I understand your troubles, but IMO 99% of Armbian users are not running kubernetes cluster and are happy with this feature enabled by default. It helps a lot - performance wise and with SD card durability. I don't see justifications to change defaults.
     
     
    Are you ticking right file:
    /etc/default/armbian-ramlog ?
     
    If disabling is not working properly, fixing it is more than welcome! And probably the right way to fix this problem.
  25. Like
    lanefu reacted to Jeremiah Cornelius in Release Announcement: TWO New, Community Unofficial Armbian MAINLINE Desktop Images for Khadas VIM3 Pro   
    I just released Armbian Focal Desktop MAINLINE images for Khadas VIM3 Pro. These are individually, pure arm64 and hybrid arm64/armhf variations.
    Thanks go to @lanefu for key pointers in understanding how to "re-arm" the firstboot and firstboot-config mechanism in current-state Armbian.
     
    Please offer feedback and experiences if you test these. The images are currently hand-built, but if enough interest is generated, and time permitting, I will commit to a git fork for an unsupported standard building process.
     

     
    I have more detail on the distribution site at archive.org, and in the corresponding posts to the Khadas forums:
     
    armhf Hybrid
    LightDM will NOT work as display manager in this configuration, and I've chromed-up lxdm as a replacement. Autologin may be a work still in progress.
    Archive.org: Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro - 32-bit Userspace - Ubuntu Focal Xfce Desktop Forums.khadas.com: Community Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro With 32-bit Userspace  
    arm64 Native
    UPDATED INFO
    HDMI audio out is non-functional with the 64-bit userspace, which is true for all Debian and Ubuntu systems, including Khadas Fenix builds.
    This capability may be a user's deciding factor in chosing between builds.
    With further testing, HDMI AUDIO NOW WORKS in arm64 image build!
    Archive.org: Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro - arm64 - Ubuntu Focal Xfce Desktop Forums.khadas.com: Community Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro arm64 Native