Jens Bauer

  • Content count

  • Joined

  • Last visited

1 Follower

About Jens Bauer

  • Rank
    Elite member

Profile Information

  • Gender
  • Location
    Herning, Denmark
  • Interests
    Programming, Jesus (active Christian - no theory - teaching / healing the sick / casting out demons), electronics.

Recent Profile Visitors

655 profile views
  1. Espressobin support development efforts

    If anyone is interested in lowering the heat from the board, I've used a 5.9V/3.8A switchmode power supply with great success. A 5.2V/2A PSU should be enough, though - my PSU just happened to be 3.8A. The Voltage range for the PSU should be above 5.2V and below 12.5V. There is an on-board 13V zener, this is in order to try and protect any attached harddisk from a spike. As for current, anything above 2A should be fine. If you're planning on powering a 3.5 inch harddisk from the board, stick with a 12.2V PSU. -If you're planning on using a 2.5 inch harddisk, you can run on low input voltage between 5.2V and 12.5V. Personally, I'll be using 2.5 inch WD Red drives because they consume very little power. I might also add a liquid cooler (cheap aluminum blocks from eBay and a silent <5dB, <6W, 0 .. 8L/min pump) - I hate noise. Note: I have not had any crashes or other issues with my 2GB boards - not even while running the boards on a 12.25V PSU with a 3.5 inch harddisk; the cooling is likely not even necessary, as the boards will be installed in an always-cold room. If, however, I add the cooling, I'll run the pump slowly, so it'll likely use less than 1W anyway.
  2. EspressoBIN: Won't boot.

    Just tried a 'strings flash-image-2g-1000_800_boot_sd_and_usb.bin' and I could not find 'load_script' anywhere. So I searched for image_name and it says: -Which indicates that this image is not what's on github. If I search for get_images, I find this: ... Does this mean that the file I downloaded is an older file, which is actually not relevant ?
  3. EspressoBIN: Won't boot.

    Before I flashed the image onto the SPI-flash, this was my U-boot version: After re-flashing, this is what I get: -So it's definitely changed.
  4. EspressoBIN: Won't boot.

    Before doing anything else, on my Mac, I made a backup-copy of the image that I flashed. Then I downloaded the image again, and did a 'diff oldimg newimg' and diff didn't say that the images were different, so the images match. I removed the old image from the USB-stick and copied the new image there anyway. I tried re-flashing the bootloader; CRC check pass and it even said that it didn't write anything this time. When I boot, I no longer get the CRC-warning I got earlier (?!??), but otherwise things stay the same. I also tried checking if the load_script environment variable was set...
  5. EspressoBIN: Won't boot.

    It never said CRC-error before, so something has changed. Perhaps this is a fail-safe / backup uboot ? Alright, I'll try re-downloading and re-flashing. Is there any way I can verify that the .bin file is not corrupt ? (I'd prefer downloaded a tar.bz2 file, so the archiver checks the archive integrity for me).
  6. EspressoBIN: Won't boot.

    I've attempted to install Ubuntu_xenial_default_4.4.112. In order to get this to work, I tried to follow the instructions on the download page as close as I could... Downloaded flash-image-2g-1000_800_boot_sd_and_usb.bin (because I have a 2GB model, which reports CPU-speed 1000 MHz and DDR 800 MHz. Formatted an USB-stick as FAT, copied flash-image-2g-1000_800_boot_sd_and_usb.bin to that stick, unmounted it. Inserted the USB-stick in the EspressoBIN, rebooted the EspressoBIN. Via the terminal I typed ... When it was done updating and returned to the "Marvell>>" prompt, I pressed the RESET button on the board. The board attempts to reboot, I get the board info, and right after the SF line, I get a warning and later a few errors... CRC-error - does that mean that the boot image was not written properly to the SPI flash ? Note: The bootcmd *has* changed; now it reads: ... As I understand it, it seems it's attempting to netboot via tftp (which is why I looked at the IP adresses). Note: I can still do a ... ... which displays the directory on /dev/sda1 (boot partition) I assume that the boot image should be "Image", but I have no clue which of the 28 .dtb files I should use. (and whether to load them from /dtb/marvell or /dtb-4.4.112-mvebu64/marvell.
  7. What's your favorite board(s) and why?

    Seems it's on it's way according to this post.
  8. What's your favorite board(s) and why?

    Yes, if the task require fast computation, the rock64 would be more interesting. -I'm not planning on doing any CPU-intensive stuff on my EspressoBIN (except from some queued compiling and probably distributed build offloading). I don't have the need for that, but I wouldn't mind if the software could take advantage of the hardware. -That could increase the use-cases for me. If that's the case, it's a bit sad - I understood from what I've read elsewhere on the net that the Topaz switch was connected via a 2.5Gbit SerDes. Did you get the information from Marvell or GlobalScale ? (As far as I understood, the Armada 3720 has two 1Gbit/2.5Gbit connections that can be connected to a switch or PHY - and one of those must be used to connect to the Topaz, which is capable of 2.5Gbit as well. So I would have expected that this was just a question of initializing hardware registers to select 2.5Gbit instead of 1Gbit - I'm only guessing here though). For this one I would respectfully disagree, though. There's of course the option to use a Mini-PCIe that gives you 2 GbE ports, or even using a Mini-PCIe splitter to utilize four GbE cards; however that's not the approach I'll try first (I may want to try it at a later point, just to see if it'll work). My attempt will be to use the Ugreen GbE adapter, which has a built-in USB 3.0 hub and then use a few extra Ugreen GbE adapters (which work with Armbian's Debian Legacy) to get more ports and hopefully saturate the USB3.0 as much as possible. I've heard from others that the GbE adapter with 3-port USB3.0 hub work with the EspressoBIN precompiled Ubuntu, so it might work with most Linux distros.
  9. Ordered 2 EspressoBIN boards

    The two boards arrived on February 13th, both in good and fully working condition. So far, I've tested buildroot and ubuntu 16.04.4 on SD-card; I've installed a bootable ubuntu 16.04.4 on a 3.5" SATA drive; also working as expected. I haven't gotten Armbian's Ubuntu working yet, but I'm pretty sure I'll get there too. So far, it's been the easiest board I've tried; it's documented well enough to solve the few issues I had (eg. mainly how to boot from SATA). I certainly felt like an expert because everything went so smooth. This is actually the first time I installed Linux on a new platform without having any real issues. I did wear out one micro-SD card while attempting to write the Armbian Ubuntu image from my Mac, but that's not an issue related to Linux; it's simply because the Medion card served its purpose. I've ordered some cheap-o-china 8GB cards that I won't be afraid of wearing out quickly - I'll use them for SATA-install anyway. I'm quite satisfied with (and fond of) the boards so far. There are still plenty of things I'd like to try out, but unfortunately I'll have to wait until I have enough money to do so. Would I recommend this board to others ? Definitely. If you have experience with other Single Board Computers, then you'd get this one up and running quickly. If you haven't tried any SBCs before, then this board is not the worst you could start with, though I think I would recommend trying out a very low-cost board first (in order to get some cheap training); such as a Nano-something-Pi - or perhaps the 1GB variant of the EspressoBIN and install the pre-built EspressoBIN Ubuntu (until Armbian's Ubuntu moves out of 'Work in Progress').
  10. Why shouldn't I buy ROCK64?

    I understand (that's what I intended to do with my CubieBoard2). My CubieBoard2 has a power-button that requires a push-and-hold in order to turn on or off. The "hold" time must be longer than 1 second, otherwise it ignores it. You might face similar issues, but it would still be possible to solve it without too much trouble. A fairly good price - I think they'll do just fine for this task.
  11. Why shouldn't I buy ROCK64?

    I've been thinking about making a watchdog (using a STM32 as monitor/power manager) for my server (CubieBoard2) -I think you could make a similar 'work-around'. Since you're monitoring the board from another board, you could actually solder two wires onto the reset button's terminals ... Eg one to the GND and one to the actual RESET signal. The other end of those two wires could simply be soldered to a relay, which is "normally open". The relay can be controlled by a transistor, which is controlled by an opto-coupler, which in turn is controlled by the monitoring SBC. This solution can definitely be optimized to include just a few components (something like a transistor, resistors and a diode), but I made a suggestion of using the relay so that it'd be easy to catch on what's going on, plus if you're using an opto-coupler, you should be able to separate the boards electrically from any accidents. You could have the Rock64 charge a capacitor, which is slowly discharged over a resistor. The monitoring SBC could then poll this capacitor (measure the voltage using one of the ADC pins), to find out whether it's running or not.
  12. What's your favorite board(s) and why?

    I'd say EspressoBIN. It has native 6G SATA (only one port, but I'm pretty sure a port-multiplier would work fine). If that's not enough, you could add a Mini-PCIe SATA card with 4 additional SATA ports (see the download page for compatibility). As for NAS performance, you'd probably not find any small SBC that has a 2.5Gbit network capability AND 6G SATA other than this board. The CPU is a 1.2 GHz dual core Cortex-A53. That might sound like it's not fast, but I bet it'd be faster for most server and NAS tasks than any board that has only a single Gbit port or a non-native 6G SATA. In addition, pfSense is on its way to EspressoBIN, so you'll soon be able to convert it into a serious router. =)
  13. Ordered 2 EspressoBIN boards

    On January 31st I decided to order two EspressoBIN boards with 2GB RAM each. What made me take the final decision was that the pfSense developers got pfSense running on the board (it's still in alpha, but it very much adds value to the board). In addition, Armbian's compatibility page (see the download page) lists two devices that I'm interested in: The USB3-to-Gbit Ethernet adapter. The Mini-PCIe-to-4-SATA-ports card. Note: This card will not be able to reach the full 6Gbit for SATA, but around 5Gbit, which is still quite good. And last but not least; Armbian of course needs some testers on this platform. Here are the things that made me get interested in EspressoBIN: The native SATA port, which has full 6G SATA speed (good for compiling, good for booting from and good for NAS, great for a router). The Mini-PCIe v2.0 slot; allows some 'final customization' to fit my needs - if I ever want to use the device for something else, it also adds flexibility there. The device is affordable. $79 is roughly the same I purchased my CubieBoard2 for, but EspressoBIN is far superior. The power consumption of the board is low; I can run it on solar panels and won't need an expensive UPS to ensure my server or router is running. The network speed will be quite fair; approximately 2.5Gbit/sec total on the three 1Gbit interfaces (since the Topaz is connected via 2.5Gbit SERDES). The board can easily be built into a 1U rack enclosure. Things that you should be aware of: If you wish to use the GPIO connectors for things other than LEDs, you should be aware that the voltage level is 1.8V, not 3.3V. That means you need a level converter if you're going to 'talk' to 3.3V or 5V electronics. In the beginning, I'll use the boards with Armbian. Then I'll move to pfSense. If/when pfSense one day runs on MacchiatoBIN, the EspressoBIN will be assigned another task (there are plenty of jobs to choose from, including servers and NAS). At some point, I hope to use one of the boards with HaProxy to load-balance a MiQi build-farm (it'll take quite a while before I get there, though). Some day, a second MacchiatoBIN will likely take over the EspressoBIN's build-farm. Conclusion: The board should be well-suited for both network and storage, the speeds would exceed most other boards in the same price range regarding this. On the other side, the CPU is a dual core CPU running at 1.2GHz, so it's little likely that it will be as quick for compiling as most of the other boards. When I move from CubieBoard2, I should see the following improvements: 32bit CPU --> 64bit CPU (slight speed increase) 1GHz dual core CPU --> 1.2 GHz dual core CPU (speed increase) SATA-via-USB --> CPU-native SATA (noticable speed increase) 100Mbit Ethernet --> 2.5Gbit Ethernet, link aggregation (noticable speed increase) HDMI output <-- no display (I use SSH anyway) 1GB DDR3 RAM --> 2GB DDR3 RAM (in the end: speed increase) 2 x USB2 -> 1 x USB3 + 1 x USB2 (speed increase on some external devices, more available accessories) Now I'm just waiting for the boards to arrive.
  14. RK3399 USB 3.0 peripheral mode data throughput?

    Thanks for clearing that up, Jose - that makes sense. I'm relieved that it's not Uniformed Army Surveillance.
  15. Disks and raid

    -And to answer your question ... It would really be easiest for you to wait until you've got all the drives you need. RAID1 requires a minimum of two drives. RAID0 requires a minimum of two drives. RAID10 requires a minimum of 4 drives. Imagine you configure your drives as RAID0, then you want to add a third drive; you'll have to erase all the data on your existing RAID0, when you add the third drive. On the other hand, if you have two drives in RAID0 and you get two more drives at the same time later on, then you might be lucky enough to be able to mirror those first two drives onto the new two drives and set up a mirror on top of those, but that's really not a good configuration. If you configure your drives as RAID1 (mirrored), then you'd also have to mess around with things when you get two more drives. It's not just a matter of duplicating the drive contents (because some sectors contain control information that identify the RAID member). -You'd have to have a RAID utility that does the work for you, so check the utility you're going to create the RAID with and see if it's capable of expanding an existing configuration. Doing the above without having a backup of your data is not a good idea, because the word 'woops' in this context means that you've lost all your data in one go. As James indirectly said: You could also start in a RAID1 configuration, then when you get the next two drives, purchase a 8TB drive or 10TB drive, back up all your data to that drive and reconfigure your RAID, then copy the data back. Note: For backup drives, it's quite convenient to purchase a USB3 harddisk docking station, they're quite affordable and speed is fair.