count-doku

Members
  • Content Count

    70
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

654 profile views
  1. Hey I just tested this myself, I did: git clone https://github.com/armbian/build cd build git checkout v19.08 sudo ./compile.sh EXPERT=yes LIB_TAG="v19.08" RELEASE=jessie Selected "Orange Pi PC", "Full image" and installation failed as you indicated: [ .... ] Fingerprinting [ o.k. ] Building package [ linux-jessie-root-orangepipc ] [ o.k. ] Building desktop package [ armbian-jessie-desktop_5.99_all ] [ o.k. ] Starting rootfs and image building process for [ orangepipc jessie ] [ o.k. ] Checking for local cache [ jessie-cli-armhf.fd2...6e9.tar.lz4 ] [ .... ] searching on servers [ o.k. ] ... remote not found [ Creating new rootfs cache for jessie ] [ o.k. ] Installing base system [ Stage 1/2 ] E: unrecognized or invalid option --components= [ error ] ERROR in function create_rootfs_cache [ debootstrap.sh:147 ] [ error ] Debootstrap base system first stage failed [ o.k. ] Process terminated [ o.k. ] Unmounting [ /home/user/build/.tmp/rootfs-default-orangepipc-jessie-no-no/ ] [ error ] ERROR in function unmount_on_exit [ image-helpers.sh:66 ] [ error ] debootstrap-ng was interrupted [ o.k. ] Process terminated So yes there seems to be a problem creating the root fs for jessie. We will not fix this because it is out of support. If you look inside the output folder though, you can see that the 3.4.y kernel was successfully created & packaged. So maybe you can use some more current (working) build and go back from there. You can downgrade your kernel with the debs created. And you could also change your apt.lists (in a running more recent install) and downgrade your stretch or whatever to jessie. Alternatively have a look at the buildscript and try to fix the sources yourself or get the rootfs from somewhere else. Maybe Orange Pi vendor? Kind regards, count-doku
  2. Apart from that 3.3V levels work just fine, the board should actually be 3.3V probably only the label has been shortened.
  3. Hi, I updated the gdoc sheet from lanefu for mvebu. Regarding the notes: Kernel 4.14 (legacy) Kernel 4.19 (current) Kernel 5.4 (dev) all work stable on mvebu (Helios & Clearfog). U-Boot 2019 is still a bit problematic on Clearfog with dev, will try to fix that until 20.05 otherwise just use U-Boot 2018 there aswell. Debian Stretch was not tested, as it is marked as unsupported on the download page ( https://www.armbian.com/clearfog/ ) . Maybe that was a typo and should have been Debian Buster @lanefu? Cheers, count-doku
  4. Looks good, I like the definitive freeze / release dates. I will do remaining work (mostly testing recent mvebu changes on Helios4) today. Another dev: @aprayoga EDIT: Not worth the extra post, I completed testing on Helios4 and Clearfog looks good: mvebu-legacy Helios4 lk 4.14.y u-boot 2018.11-armbian http://ix.io/27Ou Clearfog (Pro) lk 4.14.y u-boot 2018.01-armbian * SFP working but only up to 1Gbps http://ix.io/27OL mvebu-current Helios4 lk 4.19.y u-boot 2019.04-armbian http://ix.io/27Ox Clearfog (Pro) lk 4.19.y u-boot 2018.01-armbian * SFP working but only up to 1Gbps http://ix.io/27OM
  5. Hi, sometimes we change the layout / text which is shown in MOTD, example: Armbian 19.11.7 Buster ttyS0 clearfogpro login: root Password: Last login: Tue Jan 14 11:27:45 UTC 2020 from 192.168.1.11 on pts/0 ____ _ __ ____ / ___| | ___ __ _ _ __ / _| ___ __ _ | _ \ _ __ ___ | | | |/ _ \/ _` | '__| |_ / _ \ / _` | | |_) | '__/ _ \ | |___| | __/ (_| | | | _| (_) | (_| | | __/| | | (_) | \____|_|\___|\__,_|_| |_| \___/ \__, | |_| |_| \___/ |___/ Welcome to Armbian buster with Linux 4.19.95-mvebu System load: 1.96 0.71 0.25 Up time: 1 min Memory usage: 8 % of 1001MB IP: 192.168.1.39 CPU temp: 37°C Usage of /: 12% of 29G root@clearfogpro:~# cat /etc/armbian armbian-image-release armbian-release armbianmonitor/ armbian.txt root@clearfogpro:~# cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=clearfogpro BOARD_NAME="Clearfog Pro" BOARDFAMILY=mvebu BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=ae1737ee DISTRIBUTION_CODENAME=buster DISTRIBUTION_STATUS=supported VERSION=19.11.8 LINUXFAMILY=mvebu BRANCH=current ARCH=arm IMAGE_TYPE=user-built BOARD_TYPE=conf INITRD_ARCH=arm KERNEL_IMAGE_TYPE=Image root@clearfogpro:~# vs. login as: root root@cfp-router.clearfog.home's password: ____ _ __ ____ / ___| | ___ __ _ _ __ / _| ___ __ _ | _ \ _ __ ___ | | | |/ _ \/ _` | '__| |_ / _ \ / _` | | |_) | '__/ _ \ | |___| | __/ (_| | | | _| (_) | (_| | | __/| | | (_) | \____|_|\___|\__,_|_| |_| \___/ \__, | |_| |_| \___/ |___/ Welcome to Debian Buster with Armbian Linux 4.19.95-mvebu System load: 0.06 0.12 0.09 Up time: 22:41 hours Memory usage: 34 % of 1002MB Zram usage: 6 % of 501Mb IP: 1 92.168.1.3 CPU temp: 50°C Ambient temp: 25°C Usage of /: 7% of 459G [ General system configuration (beta): armbian-config ] Last login: Wed Jan 15 14:02:07 2020 from 192.168.1.11 root@cfp-router:~# cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=clearfogpro BOARD_NAME="Clearfog Pro" BOARDFAMILY=mvebu BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=e261c6f8 VERSION=5.91 LINUXFAMILY=mvebu BRANCH=default ARCH=arm IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm KERNEL_IMAGE_TYPE=zImage root@cfp-router:~# If you compare the welcome messages you will see, that there are some tiny differences. Both install run the same kernel (updated to that with self-built debs). Additionally the armbian-release does not seem to update. I assume this is normal behaviour, because when updating the system via apt-upgrade (or dpkg with new debs) the rootfs does not get updated. Is there a way to fix/update this? Or just copy the files from a generated full img? Regards, count-doku
  6. Honestly? I would not. The frequency with which issues about Espressobin pop up here is worse than for other NAS boards. Just skip through a thread like: I would not say Espressobin is not working, but your saying: And I am not sure you will have that experience with Espressobin. --- If you are just looking for a simple NAS board, maybe have a look at a Helios4 (if you can get them still somewhere) or Helios64 (just released). Or check out Clearfogbase (which has no SATA put pcie) or the PCEngines APU2 series: https://pcengines.ch/apu2.htm (these are x64 boards which run a mainline debian, no ARM although their power consumption is equally low). This is not meant to keep you from getting an Espressobin, but to point out possible alternatives, so you can compare them. Regards, count-doku
  7. I think the problem is, for WOL (Wake on LAN) the devices needs to be networking, so if it is completely halted that does not work -> no WOL. You are probably looking for something to "Boot on Lan". You could try to design that on your own, just get another device (which is energy efficient like ESP32 or so) to monitor for WOL request and use it to "push" the physical button on the Helios (via transistor or relay). This way you can halt the Helios completely (maybe even use a relay to disconnect the power) and reboot it from extern.
  8. Yes it is the latest (current) version. Work is still underway for kernel 5.4.y... (You can build an image yourself if you want to try it)
  9. Hi, these PIN Names are possibly considered "general knowledge" once you worked with some microprocessors or similiar. Most are just abbreviations. And the different functions on a pin. I'll try to explain some of them based on the linked OrangePi Extension header table (from their wiki): 3.3V -> obviously 3.3V output TWI0_SDA / PA12 / GPIO12: TWI0_SDA -> Two Wire Interface also known as I²C | SDA -> Serial Data PA12 -> Pin from internal pin register a, number 12 GPIO -> General Purpose Input/Output Pin Number 12 the last two are essentially the same with the first one based on the internal registers and the other one just numerated over all pins. TWI0_SCK / PA11 / GPIO11: TWI0_SCK -> Two Wire Interface (i2c) | SCK -> Serial Clock GND -> ground, minus, (-), return or whatever you're gonna call it. UART2_RX -> Universial Asynchronous Receiver and Transmitter 2 -> also known as Serial Port (RS232 like) | RX -> Receiving or Receiver. This pin is read by software. UART2_TX -> see above, TX -> Transmitter. This pin gets set by software (and sends the data) UART2_CTS -> see above, CTS -> Clear to Send. Used for flow control, to tell the partner you are ready to receive. (or they are cleared to send) (Googling for UART, USART or RS232 will probably give good explanations on this) SPI1_MOSI: SPI -> Serial Peripheral Interface -> Another kind of serial port. -> google. MOSI -> Master Out / Slave In -> this is the transmitting port for a master perspective SPI1_MISO -> Master In / Slave Out -> receiving port SPI1_CLK -> the clock signal. Just search for spi for more info. SIM_CLK / PA_EINT7: SIM_CLK -> can probably attach a SIM Card here (then this will be the clock line). I don't know stuff about sim cards though. PA_EINT7 -> Internal Port Register A, External Interrupt 7. Read about Hardware Interrupts for microprocessors for more info. Essentially a software component can be instantly triggered on some predefined signal on this pin. The rest has the same prefixes, so you can probably deduce the meaning by using the internet. If something remains unclear, just ask. Kind regards, count-doku
  10. Looks good! Congrats to the Kobol team for designing another interesting NAS board. Is the 12V 10A power supply neccessary though? I mean thats 120W, with that much power one can easily run a real x86... How much does the board itself consume?
  11. Is there maybe a problem with the driver which occurs because you connect all 3 network adapters with each other (via the switch)? only logical conclusion for me, because you said connecting to all 3 with different devices works. Maybe some layer 2/3 routing problem?
  12. Hi, I bought this relatively new WiFi card from sinovoip based on the MT7615. http://forum.banana-pi.org/t/bpi-mt7615-802-11-ac-wifi-4x4-dual-band-pcie-module-mass-production-version/10037 The kernel drivers for this are already in mainline linux (starting from 5.3 I think). I'm trying to use it on the clearfogpro though, which only runs up to kernel 4.19 right now (tried compiling 5.3 but it fails). So I wanted to backport the driver to 4.19. Unfortunately multiple things changed and trying to get the driver to compile broke lots of other stuff. So I came around to backports https://backports.wiki.kernel.org/index.php/Main_Page their documentation isn't really great for starters so I am unsure how to use this with Armbian. Has anyone used backports with armbian build system and might give me some pointers? Or is there a better way to get the driver working? Or has it even been done somewhere and I just don't find it? Greetings, count-doku
  13. Hey there are multiple things you need to check. Are you using Clearfog Pro or Base? In the title you write Pro but from the Logs it looks like you are using a Base image. This might cause problems. Apart from that check the position of the mPCIe card vs. the kernel and uboot you are using. Use this table as a guide: https://docs.google.com/spreadsheets/d/1VggzrfFibH0cmpSGW2FyoJW-d936Y2amwwKutUwX4-8/edit#gid=0 Greetings, count-doku
  14. Problem is the LEDs are partly directly connected to the ethernet switch 88E6176 (see also schematics of clearfogpro). I don't think you can tell the switch to enable/disable them. Maybe check in the driver or datasheet. Wouldn't it be easier to just put some tape over them?
  15. Can you / have you measured the 12V rail when the drives are plugged in? This sounds like a faulty supply or on board regulator which fails under load. The squeeling could be a switching regulator desperately trying to work...