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

2812 profile views
  1. That's good news, this means it is likely only be the EspressoBin is 'affected'. I just double-checked that it's not a "local error" (eg. my own stuipidity), the boot environment variables on the EspressoBin download page does load boot.scr to ${scriptaddr} and Focal's boot.scr does load armbianEnv.txt to ${scriptaddr}. ... So I'll need to try and make an armbianEnv.txt, which is large enough to overwrite the memory where the boot-script is located. Unfortunately, I currently can't get my board to boot from /dev/sda12 correctly; It keeps loading 'version 237' (from /dev/s
  2. ... Looks very similar to espressobin; I once had a setup using 'loadaddr' (not load_addr), where loadaddr was used for both loading boot.scr and armbianEnv.txt as well.
  3. I just came across this line: -Is this correct ? scriptaddr is where the boot.scr is loaded, as far as I understand, it overwrites itself by loading armbianEnv.txt to the same address. So wouldn't it be better to load armbianEnv.txt to kernel_addr, initrd_addr or fdt_addr, since armbianEnv.txt is only used for a short time ? I have not tried making an armbianEnv.txt, which is larger than boot.scr, but it looks like it would stop the board from booting if it's just long enough to overwrite the 'env import' line.
  4. After running Bionic for quite a while, I decided to move on to Focal. Focal's RESET (reboot command) seem to be very robust, it has not failed me at all. So I bet the problem no longer exists with Focal and would like to recommend upgrading.
  5. Thank you for your advice, I'll take it with lots of appreciation! :) I'm currently in the process of restoring my server, so I'll have to wait a few days, but I will try with a fresh installation of the most recent image from the download page. Unfortunately I only have one ZXSP drive, so I can't test with several drives of this type - it could have been very useful to know if it really depends on this drive type. Just in case someone reading this should be tempted: I think it's a bad idea to use BLUE (desktop drives) for a server - RED are much more stable.
  6. I just experienced this old problem with Focal: WD drives inaccessible starting with kernel 4.13 -As the topic is now closed, I'd like to add some information. My drive is a 2.5" 1TB WD10SPZX (WD BLUE). It was connected via a port-multiplier. Normally I use only WD RED, but I had to move some large files, so I attached it temporarily. Here's stack-trace #1... Stack-trace #2: I tried reading a large tar-file several times from the drive, but Focal kept crashing. After that, I tried switching to a WD BLUE (Slim)
  7. Fairly understandable. Cortex-A73 is by design (eg. ARM) using lower power and produces lower heat than Cortex-A72. Cortex-A75 even lower power and quicker than Cortex-A73. -So it will likely pay to choose the latter implementation over the former, even if the price of the CPU is higher. For build-farms and quick data-processing, it's interesting having high-speed CPU cores and high speed network (this can be spread out on several GbE ports or just a single 10GbE port). 2GB or 4GB LPDDR4 would also be attractive for this kind of configuration. Native 6G SATA would be
  8. Please add native SATA to the list. :) -I think it would not hurt to change the x4 PCIe3 to a four x1 PCIe3 or even four x1 PCIe2. -That way you can easily add cheap SATA host controllers or GbE adapters (with four GbE connectors per card). The 8040 is expensive, but I'd rather purchase one working board with extreme specs than 3 or 4 almost-working boards. -So for me, it takes time to save up for the MacchiatoBIN, but it's definitely worth it; and I want two DoubleShot boards!
  9. A while back, I noticed that Armbian was compatible with this Ugreen GbE adapter. As I purchase on eBay rather than Amazon, I found the above one plus this adapter, which has the same AX88179 chipset plus a built-in 3-port USB3-Hub. So I decided to try it and see if it worked with Armbian and report back here. (I'm using the EspressoBIN for this and Ubuntu Bionic 4.19.56). These are my results: Straight out-of-the-box, I can see it using LSUSB, but it does not plug-and-play-work. After struggling and attempting to get the network manager to do something abo
  10. Mini-PCIe is good a thing, you've got this one right! -But the specs need to be better on a SBC today. RockPro64 is doing things the right way; they pack the SBC with good specs while keeping the price as low as they can, resulting in a board with great specs, for a slightly higher price than the average boards (but it'll pay for the end-user to get this board rather than the lower priced ones). My personal priority list: PCIe2.0 or PCIe3.0 (x4 or more if possible). CPU-native 6G SATA (at least one port, but 3 ports would be very attractive) Low power consumptio
  11. Sadly it's not affordable for me. I'll still have to wait at least 3 months until I can purchase one. -But as you might have read elsewhere, I do plan on getting a couple of MacchiatoBIN boards. Even if the CPU is 3 years old, it's still very capable, compared to those we get on other SBCs today. But for me, the hardware is just as important; high speed networking, lots of quick RAM, native SATA ports and PCIe 3.0 is something I very much need. The board is a robust high-quality board and I'd expect it to last longer than any of my current boards. I will need to get/create some
  12. I guess I'm lucky to have two 1GB models, because they're likely faster than both the 2GB and 4GB models. I wonder why they didn't equip the 4GB model with heatsinks or cooling fans, so that we could see the max. speed (which is kinda what it's about). Some of us live on the south pole, some of us live on the equator; running the same benchmark in different locations will give different results unless making some basic temperature control...
  13. And that was exactly what I was missing! Now it seems my worst problem has passed. Thank you very much, @ebin-dev!
  14. Sorry, I was sloppy when I wrote the comment. What I meant was to cut them "inside" the adapter -eg. between the plugs. Thus I bet it should be possible to keep for instance CC1 and then put a 5K1 pull-down resistor on CC2 "inside" the adapter and then not connect CC2 to male-plug (which would connect to the RPi4).
  15. Yep. They have acknowledged it and said that they're fixing the problem for next revision which should be out in "less than two months" (they've probably already fixed the schematics and PCB-layout, but I guess actual production slow down things). As a workaround, wouldn't it be possible to disconnect CC1 or CC2 or both and then add the resistor inside an adapter-cable [USB-C female-to-male] ?