• Content Count

  • Joined

  • Last visited

About count-doku

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location

Recent Profile Visitors

735 profile views
  1. Yeah that might work. Keep in mind though that this module will still output 3.3V if the input is lower than 5V. Checking the datasheet it seems like this regulator has a dropout voltage of about 1.2V. So 4.5V input would still allow this module to output 3.3V signaling to your SBC that everything is OK while at 4.5V input to your SBC it will probably fail. This is obviously not ideal! EDIT: Easiest way to do it would be to instead of the converter just use a potentiometer (10k or something like that). Connect the ends to 5V and GND, and adjust it until the slider is at about 3V (measure with multimeter). Then attach the slider pin to some GPIO and check GPIO state. Keep turning down the voltage just until the GPIO reads as LOW. Turn back up a bit until it is HIGH. Then once the input drops below 5V the poti output will also drop slightly causing the GPIO to go LOW -> use this as shutdown. This is also not perfect, beware: never turn the poti to high (watch out for anything >3.3V on your GPIO) also you might have to experiment 'till you have a good setting. Minor power fluctuations should not cause a shutdown.
  2. No it does not get mirrored automatically. What you did is create a PR from your robstroess-patch-1_bond-uptime branch to your master branch. What you need to do is go here: And create a PR from your robstroess-patch-1_bond-uptime branch to our master. So robstroess:robstroess-patch-1_bond-uptime to armbian:master. Hope this helps, don't give up, Github is one complicated beast but Igor is right, once you know it a bit it is really helpful. For reference: Robs PR: Cheers Count-Doku
  3. You don't seem to have enough understanding for building an image yourself. Why don't you just download a pre-built one? Find your board here Choose either Debian or Ubuntu, burn to sd card with etcher, insert it into your board and you're done.
  4. Is this not easily possible by using LIBTAG parameter? Or does it not work anymore? Apart from the final release confusion I'd also totally agree with JMCC this release process was way better than older ones.
  5. Suggestion for future releases: On the release date / once it's released make a topic in Announcements telling people of the new release. Or is Twitter now the main way to communicate such things?
  6. I was not expecting you to put more time into it. It was more directed at the original poster, to address the issues pointed out by you. And to give him an idea what he could do to make it work with a powerbank...
  7. You could just add some larger capacitor in parallel to the power bank. If chosen right it should surpress the voltage spike and buffer enough so it does not drop. Might even use more than one to get a better frequency response. Or put a 5.2 volt zener / tvs diode across the board to protect it from the spike. I can edit this with some wiring later if needed. EDIT: Some wiring idea: Use some resistor voltage divider on the powerbank input (eg. 10k to 10k which gives you 0.5) to get some measurement to your sbc. With the given voltages this would be: 5V in -> 5V * (10k / (10k + 10k)) = 5V * 0.5 = 2.5V . If you feed this to some GPIO you can either use some analog pin to measure it directly (and initiate shutdown if it goes to low) or you can hook it up to some digital one if you only want to know wether it is high or low. Might need to change the resistor ratio then. Do not exceed your max gpio voltage! On the Powerbank output add either D1 or D2 (zener or transient voltage surpressor diodes) rated for slightly above 5V. These will get rid of nasty voltage spikes for you. Additionally use some small capacitor (to remove high frequency ripple) and some larger one in parallel (to reduce low frequency ripple / voltage drops) to buffer over the voltage drop when powerbank is switching on / off. Cheers, count-doku
  8. I am confused now. #armbian tells us that v20.02 has been released. Where was the release date 28.02. defined? First post in this thread still says "Release Date: 2020-02-?? (will update thread)". Is it always going to be ~1month after feature freeze? Probably. How does work continue now? Does somebody port fixes from 20.02 to master? I assume we will continue development on master so it would make sense, to get all fixes from 20.02 over to it. What happens with rc0 and rc1 ? Just stale and delete at some point? Regards, count-doku
  9. I have no idea why dd would not work, but as a workaround you could: use Win32Diskimager to create an *.img file from your old sd card. Than use Win32DiskImager or Etcher to burn that file to the new sd card. Worked good for me.
  10. I agree with the previous posters. Any supported / recommended board will run stable with most features working if you use good PSU (not micro-usb), sd card (or even better root on emmc or sata) and is sufficiently cooled. I'd suggest you go for boards with good mainline linux support (ie. 4.19 or 5.4) because more hardware is supported & if something breaks there are possibly more people fixing it versus boards which only have some old vendor kernel. Apart from that unfortunately it is like you said, not every feature works on every board. In my experience this is mainly due to hardware producers advertising (hardware) functions although there is no real software support for it. Or randomly changing hardware (see espressobin) which breaks existing software... I suggest thinking about stuff you really need and picking a board afterwards. (You probably don't need an "Eierlegendewollmilchsau"). Personal experience: I'm running a Router/NAS based on ClearfogPro with M.2 SSD for OS, 2x HDD for storage (with mPCIe-SATA bridge) for about 3 years now with no problems (apart from stuff which I broke be installing dev kernels and so on). So, I am sending in the Clearfog Army!
  11. @TRS-80you did realize those are AMD processors, right? So there's probably no Intel ME in there In case you were worrying because AMD processors might contain the same, well true. Regarding the firmware for the board (which is coreboot) you can check the firmware maybe this helps?
  12. Please try a 19.x build. The 20.02 ones are only RC (release candidates), it is a bug / mistake that the general link points to them.
  13. Hey, just realized if users currently go to, example: and select the buster_current download directly, they get the RC releases. This is probably not wanted behaviour. Cheers, count-doku
  14. Hi, I recently built a NAS using the APU2E4 ( which gives you 4 cores (I think all APU2 have 4 cores so smaller versions should work just fine), and 4GB RAM. 3 Gbit LAN, 1 SATA, 2xmPCIe (which give you up to 8 SATA), and mSATA (you could use a breakout board or some actual mSATA drive for ssd / os). It is working pretty good. Installation was a breeze, stock debian with mainline kernel works nicely. Thanks to being x64 and not some ARM all hardware worked out of the box. Performance using ext4 harddisk drives and LAN peaked at about 120MB/s write (which is the max of the drives I assume). I did not test any cluster fs. Remember that you might need to build your own cooling solution, the boards ship only with some "heatspreader" (aka alu plate) which normally transfers heat to their enclosure. Regards, count-doku
  15. That depends on the board. But mostly u-boot sits directly on the device (before the partition) and then loads the kernel etc. from /boot. Same as on x86 grub gets also installed to mbr...