guidol

  • Posts

    1737
  • Joined

  • Last visited

Reputation Activity

  1. Like
    guidol reacted to BarTender in Odroid C2 : no eth0 with latest image   
    Just had the same problem as well, was running Buster without an issue on my C2 and needed to move to Focal for a few annoying reasons using the non desktop download https://redirect.armbian.com/region/AS/odroidc2/Focal_current and can see I also have the same issue with uboot failing to find the network adapter. I can pull the version out of the running Bionic image and then dd it onto the eMMC.
    I eventually got my host working by taking the uboot from Bionic:
    wget https://armbian.systemonachip.net/archive/odroidc2/archive/Armbian_20.02.8_Odroidc2_bionic_current_5.4.28_desktop.7z 7z e Armbian_20.02.8_Odroidc2_bionic_current_5.4.28_desktop.7z dd if=Armbian_20.02.8_Odroidc2_bionic_current_5.4.28_desktop.img of=bionicuboot.bin bs=512 seek=1 skip=1 count=4096 then put onto the emmc: dd if=bionicuboot.bin of=/dev/sdb bs=512 seek=1 skip=1  
    Further edit.. I am going to search for my serial console tonight when I get home to help debug the root cause. I am also running the same C2 board revision as @guidol as per this post: 
     
  2. Like
    guidol reacted to qualle337 in Fail to Boot with Serial Device Connected to USB   
    Yes - looks like you're right! Thanks for pointing me in this direction. I'll update the thread when I found a solution (other than plugging in the Arduino after the boot) in case someone else has similar issues.

    Cheers,
    Julius
  3. Like
    guidol reacted to griefman in Failing to Boot   
    So, 
    after struggling for quite some time i finally was able to get things back to normal without losing data (at least i think so).
     
    The problem was apparently a broken kernel upgrade to version 5.10.43 . There were broken symlinks and not only. 
     
    In the end what solved it was the following:
    I first put the latest stable armbian on an sd card and booted with it. then i actually upgraded that image to the latest kernel and copied all version related files from /boot of the sd card to the /boot of the mmc. I also copied the 5.10.45 modules from /lib/module from the sd card to the mmc.
    Fixed all symlinks in /boot and then the device finally booted. After that it was all about reinstalling kernel headers, cleaning up wrong zfs versions and packages and rebooting frequently enough in between
     
    Hope that i didnt break too much and that this helps someone.
  4. Like
    guidol reacted to bartek666666 in Allwiner A10 tablet USB not working [SOLVED]   
    Okay, I'm a noob but finally it works. .dts for anyone that is curious. now i just need to enable LCD in u-boot
     
    /dts-v1/; #include "sun4i-a10.dtsi" #include "sunxi-common-regulators.dtsi" #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/pwm/pwm.h> / { model = "Cubietech Cubieboard"; compatible = "cubietech,a10-cubieboard", "allwinner,sun4i-a10"; aliases { serial0 = &uart0; }; chosen { stdout-path = "serial0:115200n8"; }; hdmi-connector { compatible = "hdmi-connector"; type = "a"; port { hdmi_con_in: endpoint { remote-endpoint = <&hdmi_out_con>; }; }; }; }; &ahci { target-supply = <&reg_ahci_5v>; status = "okay"; }; &codec { status = "okay"; }; &cpu0 { cpu-supply = <&reg_dcdc2>; }; &de { status = "okay"; }; &ehci0 { status = "okay"; }; &ehci1 { status = "okay"; }; &emac { phy-handle = <&phy1>; status = "okay"; }; &emac_sram { status = "okay"; }; &hdmi { status = "okay"; }; &hdmi_out { hdmi_out_con: endpoint { remote-endpoint = <&hdmi_con_in>; }; }; &i2c0 { status = "okay"; axp209: pmic@34 { reg = <0x34>; interrupts = <0>; }; }; &i2c1 { status = "okay"; }; &ir0 { pinctrl-names = "default"; pinctrl-0 = <&ir0_rx_pins>; status = "okay"; }; &mdio { status = "okay"; phy1: ethernet-phy@1 { reg = <1>; }; }; &mmc0 { vmmc-supply = <&reg_vcc3v3>; bus-width = <4>; cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */ status = "okay"; }; &ohci0 { status = "okay"; }; &ohci1 { status = "okay"; }; &otg_sram { status = "okay"; }; &pio { usb0_id_detect_pin: usb0-id-detect-pin { pins = "PH4"; function = "gpio_in"; bias-pull-up; }; usb0_vbus_detect_pin: usb0-vbus-detect-pin { pins = "PH5"; function = "gpio_in"; bias-pull-down; }; }; &reg_ahci_5v { status = "okay"; }; #include "axp209.dtsi" &ac_power_supply { status = "okay"; }; &reg_dcdc2 { regulator-always-on; regulator-min-microvolt = <1000000>; regulator-max-microvolt = <1400000>; regulator-name = "vdd-cpu"; }; &reg_dcdc3 { regulator-always-on; regulator-min-microvolt = <1000000>; regulator-max-microvolt = <1250000>; regulator-name = "vdd-int-dll"; }; &reg_ldo1 { regulator-name = "vdd-rtc"; }; &reg_ldo2 { regulator-always-on; regulator-min-microvolt = <3000000>; regulator-max-microvolt = <3000000>; regulator-name = "avcc"; }; &reg_usb0_vbus { status = "okay"; }; &reg_usb1_vbus { status = "okay"; }; &reg_usb2_vbus { status = "okay"; }; &spi0 { pinctrl-names = "default"; pinctrl-0 = <&spi0_pi_pins>, <&spi0_cs0_pi_pin>; status = "okay"; }; &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_pb_pins>; status = "okay"; }; &usb_otg { dr_mode = "host"; status = "okay"; }; &usbphy { pinctrl-names = "default"; pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>; usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ usb0_vbus_det-gpio = <&pio 7 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; /* PH5 */ usb0_vbus-supply = <&reg_usb0_vbus>; usb1_vbus-supply = <&reg_usb1_vbus>; usb2_vbus-supply = <&reg_usb2_vbus>; status = "okay"; };  
  5. Like
    guidol reacted to Dan MacDonald in CH340-fan-control - USB fan control script   
    I own a few Android TV boxes that have poor thermal designs that are prone to overheating when under sustained load. This can either cause your device to significantly slow down or shut down entirely. This can be fixed by cutting a hole in the bottom on your TV box above the SoC and sticking a small USB fan on it. In my case I am using a AC Infinity 40mm x 20mm USB Fan that cost me £10.
     
    CH340-fan-control is a python script to only activate my TV boxes USB fan when required by using a USB relay module. I'd expect somebody (or several somebodies) have already wrote a similar script for the same device but I failed to find it so here is my effort at fixing this common TV box issue. Hopefully someone else will find it useful.

    https://github.com/danboid/CH340-fan-control

     


  6. Like
    guidol reacted to lanefu 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?

     
     
     
  7. Like
    guidol reacted to PietreLinux in Tablets q8(a13,a23,a33) support??   
    Hello everyone, I wanted to propose that the q8 tablets be included in the compilation script, I have several q8 tablets, at the beginning I used my own rootfs, but armbian is fantastic !! counting the modifications I make to the armbian rootfs I think it would be easy, in the firmware repository you already have the majority of hardware such as 8723 and other Wi-Fi chips, with respect to the uboot the templates that already incorporate the main repository work almost perfectly, no I know, could I help, I have the components, the dtb and the compiled uboot, how do you see it? Greetings
  8. Like
    guidol got a reaction from sami in serial data with framing bits(Nanopi Neo Core)   
    you could try the socat command  which supports some raw-configuration.
     
    I use it to "copy" the stream from /dev/ttyUSB0 to /dev/ttyUSB1 for connecting 2 USB-serial devices on a armbian-SBC
     
     
     
     
     
     
     
     
     
     
     
  9. Like
    guidol reacted to NicoD in Real time operating system   
    I was thinking exactly the same question. Why do you bother and waste your time here if you don't like Armbian?
    Lately I've red few complaints of people who have "many years of experience". But they don't want to bother reading and learning new skills. 
    Experience is not the same as knowledge
    As knowledge is not the same as experience

    With experience you can have gained knowledge about much but not being specialized at one thing, or know a lot about a small section of the industry and be blind to all other.

    Thousands of people happily use Armbian on their devices and for 99% of the usecases everything is fine. The other 1% we try to help here. 

    I've made tons of informative videos about SBCs. I show how to do all the basic stuff, and some more advanced things. 
    https://www.youtube.com/channel/UCpv7NFr0-9AB5xoklh3Snhg/search?query=armbian
    The forum also has the Reviews, Tutorials and Hacks section where almost everything you could want to learn about Armbian is explained.
    https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/
    Then there is Armbian Docs also full of information.
    https://docs.armbian.com/

    All these things have cost us time, and so also money. We are here to serve. And then you say our work is "garbage".
    Sorry, but I do not take that lightly.

    You can't teach someone who is convinced to know it all. Greetings.
  10. Like
    guidol reacted to Pali in How to make ESPRESSObin v7 stable?   
    I have sent that fallback vdd voltage patch to Marvell: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/pull/18
  11. Like
    guidol reacted to lanefu in Make forum messages friendlier -- 2021 Edition!   
    Per meeting, we're still trying to improve our responses to "unsupported' inquries.

    current thoughts
     
    * revise "invalid label"
    * focus on moving messages
  12. Like
    guidol got a reaction from malaga in [Invalid] - operating-system wanted for the Alwinner A 20 - which one to take   
    find at https://www.armbian.com/download/ all downloads
     
    - Alwinner /banana Pi A 20
    https://redirect.armbian.com/bananapi/Buster_current 

    - Udoo Quad Makerboard Rev. D.
    https://redirect.armbian.com/udoo/Buster_current

    - Orange PI Prime rev 1.0 
    https://redirect.armbian.com/orangepiprime/Buster_current_xfce
  13. Like
    guidol got a reaction from Werner in Need your help - what else beside Etcher   
    Info on Reddit
     
     
  14. Like
    guidol reacted to martinayotte in Bug GUI Armbian on Pinebook   
    I've tried for months to clarify the reason of such issue ...
    My last working kernel was 5.7.6, and the issue appeared as soon as 5.8.0, I've done "diff" between both branches and I still didn't figured out the glitches ...
  15. Like
    guidol reacted to balbes150 in Jetson Nano   
    New version of Armbian 20210311.
    Based on the main core 5.10.23.
    Now anyone can build their own version of Armbian for Jetson Nano without an external PC, the entire process is completely performed on the Jetson Nano itself.

     
  16. Like
    guidol got a reaction from Igor in Odroid C2 : no eth0 with latest image   
    @Igor @Elclaudio
    My C2 did already work/reboot with 
    U-Boot 2021.01-armbian (Mar 03 2021 - 14:32:21 +0300) odroid-c2
     
    But today I compiled the new u-boot
    U-Boot 2021.04-rc3-armbian (Mar 08 2021 - 18:12:26 +0300) odroid-c2
    which does also work/reboot fine on my C2
    System diagnosis information has been uploaded to http://ix.io/2SaS
     
    [EDIT]
    does also work with newer dev-kernel
    FROM Linux 5.10.19-meson64 TO Linux 5.11.4-meson64
    System diagnosis information has been uploaded to http://ix.io/2SaU

     
     
    # dd if=/dev/mmcblk0 of=/tmp/installed_uboot.bin skip=97 count=1376 1376+0 Datensätze ein 1376+0 Datensätze aus 704512 bytes (705 kB, 688 KiB) copied, 0,0525366 s, 13,4 MB/s # strings /tmp/installed_uboot.bin | grep "U-Boot 20" U-Boot 2021.01-armbian (Mar 03 2021 - 14:32:21 +0300) odroid-c2 # dpkg -i ./linux-u-boot-dev-odroidc2_21.05.0-trunk_arm64.deb cd /usr/lib/linux-u-boot-dev-odroidc2_21.05.0-trunk_arm64 dd if=./bl1.bin.hardkernel of=/dev/mmcblk0 bs=1 count=442 conv=fsync > /dev/null 2>&1; dd if=./bl1.bin.hardkernel of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1; dd if=./u-boot.bin of=/dev/mmcblk0 bs=512 seek=97 conv=fsync > /dev/null 2>&1 [reboot] # dd if=/dev/mmcblk0 of=/tmp/installed_uboot.bin skip=97 count=1376 1376+0 Datensätze ein 1376+0 Datensätze aus 704512 bytes (705 kB, 688 KiB) copied, 0,04659 s, 15,1 MB/s # strings /tmp/installed_uboot.bin | grep "U-Boot 20" U-Boot 2021.04-rc3-armbian (Mar 08 2021 - 18:12:26 +0300) odroid-c2  
    linux-u-boot-dev-odroidc2_21.05.0-trunk_arm64.deb
  17. Like
    guidol reacted to Igor in Odroid C2 : no eth0 with latest image   
    @Elclaudio This could provide a fix. Change to nightly builds (armbian-config -> system -> nightly) and see if things are better. Patch is already in that code.
  18. Like
    guidol reacted to Adrian Cable in H2/H3: "old problem" Link (eth0) is Up/Down syndrom   
    We have a commercial product running on Armbian based on the OPi Zero platform. We occasionally get reports from customers of intermittent connectivity, which (looking at the dmesg log on affected devices) manifests itself as something that looks very much like the up/down syndrome reported here. In this case we advise customers to purchase a cheap switch (e.g. https://www.amazon.com/NETGEAR-5-Port-Gigabit-Ethernet-Unmanaged/dp/B07S98YLHM/ref=sr_1_3?dchild=1&keywords=4+port+switch&qid=1614793487&sr=8-3) and put it between our product and their existing switch or router. We have found this always resolves the issue.
     
    We still don't understand the cause, but at least we have a workaround (albeit not a perfect one).
  19. Like
    guidol reacted to Dbrooks in Odroid C2 : no eth0 with latest image   
    Elclaudio, you're a legend.  Shoved ye olde uboot on and bam... eth0 is back.
     
    Thank you!!
     
    Not a fix, but it's enough of a workaround for my needs.
  20. Like
    guidol reacted to Elclaudio in Odroid C2 : no eth0 with latest image   
    OK I FOUND THE CULPRIT ! the issue come from UBOOT like I imagined. After installing older uboot ETH0 worked straight away
    Since I couldn't find the uboot .deb used in my old armbian 5.95 in https://imola.armbian.com/apt/pool/main/l/
    I took the uboot files from my WORKING armbian version kernel 4.19.69 in /usr/lib/ linux-u-boot-next-odroidc2_5.95_arm64
    there should be 2 files : bl1.bin.hardkernel  and u-boot.bin
    copy them wherever you want on the latest armbian (currently in test : Armbian 21.02.2 Buster with Linux 5.10.16-meson64,) Linux odroidc2 5.10.16-meson64 #21.02.2 SMP PREEMPT Sun Feb 14 21:50:52 CET 2021 aarch64 GNU/Linux
    I backed up the original files in the same directory with .ORI extension
    Then I run the commands here
     
    If you do it beware with dd it could crash your partition if missused, also adapt the paths and filename to your particular case.
     
    #!/bin/bash # install older uboot from armbian kernel 4.19.69 dd if=/root/uboot/bl1.bin.hardkernel.OLD of=/dev/mmcblk0 bs=1 count=442 conv=fsync > /dev/null 2>&1; dd if=/root/uboot/bl1.bin.hardkernel.OLD of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1; dd if=/root/uboot/u-boot.bin.OLD of=/dev/mmcblk0 bs=512 seek=97 conv=fsync > /dev/null 2>&1 # restore original uboot #dd if=/root/uboot/bl1.bin.hardkernel.ORI of=/dev/mmcblk0 bs=1 count=442 conv=fsync > /dev/null 2>&1; #dd if=/root/uboot/bl1.bin.hardkernel.ORI of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1; #dd if=/root/uboot/u-boot.bin.ORI of=/dev/mmcblk0 bs=512 seek=97 conv=fsync > /dev/null 2>&1  
    It would be nice now to debug what's gone wrong with uboot code...
  21. Like
    guidol reacted to martinayotte in [Warning] NPi K1 Plus (not Pihole) seems to have trouble with kernel 5.11.1   
    If you look at the resulting image, maybe the rtl8189fs.ko is still present and broken ...
     
    Anyway, I've done builds+tests on all my OPi which using this rtl8189, and results are successful, I've done this commit :
    https://github.com/armbian/build/commit/bba53d4644e83cd46b80820b5835ad7c2e7691e5
  22. Like
    guidol got a reaction from Werner in [Warning] NPi K1 Plus (not Pihole) seems to have trouble with kernel 5.11.1   
    As a test I updated on a secondary Pihole-Server (buster on NanoPi K1 Plus) the kernel to 5.11.1-dev and at startup Pihole did seem to make some trouble
    The server isnt getting to the login prompt and on the serial console the last info is "Starting kernel..."
     
    I updated some of my SMB-Servers with kernel 5.11.1-deb without problems.
     
    Will later try a new resinstall with buster and 5.11.1 and see if Pihole will run on a complete new installation.
     

  23. Like
    guidol reacted to tparys in What diffirend armhf and arm64 for .deb packets?   
    Some additional information for the curious ... https://www.debian.org/ports/arm/
    The ARM EABI (armel) port targets a range of older 32-bit ARM devices, particularly those used in NAS hardware and a variety of *plug computers. The newer ARM hard-float (armhf) port supports newer, more powerful 32-bit devices using version 7 of the ARM architecture specification. The 64-bit ARM (arm64) port supports the latest 64-bit ARM-powered devices.
  24. Like
    guidol reacted to Werner in What diffirend armhf and arm64 for .deb packets?   
    Moved to proper location.
    armhf is 32bit
    arm64 is 64bit.
     
    There are a few other variants of arm in 32bit which you can lookup via Wikipedia for example
  25. Like
    guidol got a reaction from DominicanGuy in Updated armbian-config v5.81   
    Did create a more compact version for me (and you?)
     
    nano /etc/update-motd.d/10-armbian-header ARMBIAN_bsp=$(more /etc/armbian-release|grep VERSION|cut -f 2 -d '=') ARMBIAN_kernel=$(dpkg -s linux-image-$BRANCH-$LINUXFAMILY|grep Version|cut -f 2 -d ' ') ARMBIAN_uboot=$(dpkg -s linux-u-boot-$BOARD-$BRANCH|grep Version|cut -f 2 -d ' ') ARMBIAN_dtb=$(dpkg -s linux-dtb-$BRANCH-$LINUXFAMILY|grep Version|cut -f 2 -d ' ') ARMBIAN_firmware=$(dpkg -s armbian-firmware|grep Version|cut -f 2 -d ' ') ARMBIAN_config=$(dpkg -s armbian-config|grep Version|cut -f 2 -d ' ') printf '\n' printf 'pkg-version kernel[\e[0;91m%s\x1B[0m] u-boot[\e[0;91m%s\x1B[0m] dtb[\e[0;91m%s\x1B[0m] firmware[\e[0;91m%s\x1B[0m] config[\e[0;91m%s\x1B[0m]\n' "$ARMBIAN_kernel" "$ARMBIAN_uboot" "$ARMBIAN_dtb" "$ARMBIAN_firmware" "$ARMBIAN_config" printf '\n'