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

1311 profile views
  1. I'm not really keen on running Debian. Partly because I'm already running a complete Xenial setup on my "production server" and wouldn't like to switch. Besides, things look kinda more promising now than a few months ago, since I've actually been able to get some network availability from 'nothing'. I'm pretty sure that someone who knows more about Linux networking than me, would know how to easily fix the 4 mentioned issues. I've been practicing a little with nmcli (not at all experienced with this tool), and have gotten slightly further; none of the issues have been fixed, though. Using nmcli, I've been able to add an IP-address/range, a gateway and two ipv4.dns addresses to 'bond0'. I still have to do all this by hand every time, so at the moment I've switched back to an earlier version of Bionic, since I'm using the board as a file server too.
  2. I had another go at Armbian_5.68_Espressobin_Ubuntu_bionic_next_4.19.12.7z and had some progress: This is exactly what happens on first boot, right after a clean installation. Let's try and resolve a domain name $ systemd-resolve resolve call failed: Failed to activate service 'org.freedesktop.resolve1': timed out (service_start_timeout=25000ms) So it didn't work; Let's get some status information on systemd-resolve $ systemd-resolve --status Failed to get global data: Connection timed out Seems it's not paying attention, now let's see which version is installed $ apt policy systemd Installed: 237-3ubuntu10.9 Candidate: 237-3ubuntu10.9 Version table: *** 237-3ubuntu10.9 500 500 bionic-security/main arm64 Packages 500 bionic-updates/main arm64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 bionic/main arm64 Packages Try and re-activate it $ sudo systemctl restart systemd-resolved.service Now let's try and resolve a domain name $ systemd-resolve resolve call failed: No appropriate name servers or networks for name found The error-message has changed, we probably had some progress, let's see if we have a DNS address $ grep -v '#' /etc/systemd/resolved.conf [Resolve] DNS= Not exactly what I wished for, so back up resolved.conf and replace by OpenDNS # cd /etc/systemd # cp -n resolved.conf resolved.conf.orig # echo -e "[Resolve]\nDNS=" >resolved.conf # systemctl restart systemd-resolved.service Check if the changes took place $ systemd-resolve --status | grep 'DNS Server' DNS Servers: Let's see if we can ping our gateway $ ping connect: Network is unreachable Looking at the LED on the WAN port's 8P8C, only one LED is turned on $ ip link | grep wan 5: wan@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 Try turning on the LED on the WAN port # ip link set wan up (could also use: # ifconfig wan up) both 8P8C LED lights are now on, let's see the changes $ ip link | grep wan 5: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 OK, now see if we can look up a domain name $ systemd-resolve resolve call failed: No appropriate name servers or networks for name found Still no luck, try and see if we can ping the gateway $ ping connect: Network is unreachable OK, let's add an ip-address to the WAN interface and see if that helps # ip addr add dev wan $ ping Now pings get through, let's try and see if we can make a domain name lookup $ systemd-resolve resolve call failed: All attempts to contact name servers or networks failed No dice, but I can SSH into the EspressoBIN board from another computer, so I have network, but the resolver is not working. Issues: Network is not brought up by default. Resolving does not work out-of-the-box. IP address does not survive a reboot, thus no servers can start up at boot. Resolver still does not work, even after getting the network up and running, thus I can not install software via 'apt'. I do not know how to get any further from here, but hopefully this is helpful to someone.
  3. I just tried installing Armbian_5.68_Espressobin_Ubuntu_bionic_next_4.19.12.7z but ... Now there's absolutely no network at all. Earlier I had to do an 'apt update; apt upgrade' in order to make it impossible to connect to anything. Now, if I install Bionic, I have no network right from the start; I do not need to do anything. Have anyone succeeded in getting network on Bionic (after doing an 'apt upgrade') the past 3 months ?
  4. ... Besides, it's probably just those people behind bot-nets that are responsible ... make sure you use SSH-keys for logins and disable password authentication.
  5. Heh, we can't really know for sure exactly what happened, but there's a pretty good chance that it's not all fantasy. We know it's definitely technically possible to do this - and I'd say it's likely that it happened (if a large company says 'minor security breach', it's likely not just minor...) I kept thinking through reading the article ... why didn't they hide between the PCB layers ... and 3/4 through the articles that was actually mentioned as well. But the next thing would likely be to implement such junk inside CPUs or other chips. Intel-based devices are just very interesting, because they're mainstream and they're everywhere. ARM is also widely spread by now - this makes the ARM architecture a target. Maybe this won't happen through the CPU itself, but "bad RAM" would likely be the most likely way it would be implemented. -So now CPU vendors need a way to verify that the RAM is not modifying its contents on its own... Security by obscurity might not be so bad after all... Using a good old Z80, which noone expects in a modern computer, could protect against such attacks.
  6. Did you read about this security hack ? (Bloomberg)
  7. I tried posting yesterday, but when I clicked 'submit reply', the forum web-site was gone and so was everything I typed. :/ I can't reconstruct my post, but I gave an example on how little is actually needed; fortunately, I had that in my copy-and-paste buffer, so here it is: # Set boot arguments: setenv bootargs 'console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk1p1 rootfstype=ext4 rootwait loglevel=1' # load kernel file 'boot/image' to RAM at address 0x5000000: ext4load mmc 0:1 0x5000000 boot/image # load fdt file to RAM at address 0x4f00000: ext4load mmc 0:1 0x4f00000 boot/dtb/marvell/armada-3720-community.dtb # execute kernel in RAM: booti 0x5000000 - 0x4f00000 -Actually 'loglevel=1' is not strictly necessary, but there's no reason to be impolite. The above will only boot from partition 1 of the micro-SD card, but it's so short that it gives a fairly easy overview (in commands) of what's basically going on. The 'bootargs' environment variable is special; it's actually read by the Linux kernel. Anyway, I gave another example on how the environment variables could be added back in, in order to make it more readable with the stuff you might want to change at the top: setenv iface mmc; setenv dev 0:1; setenv root '/dev/mmcblk1p1' setenv image_name 'boot/image' setenv fdt_name 'boot/dtb/marvell/armada-3720-community.dtb' setenv kernel_addr 0x5000000; setenv fdt_addr 0x4f00000 setenv console 'console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000' setenv bootargs "$console root=$root rootfstype=ext4 rootwait loglevel=1" ext4load $iface $dev $kernel_addr $image_name ext4load $iface $dev $fdt_addr $fdt_name booti $kernel_addr - $fdt_addr -As you see, it's a lot easier to see what's going on if adding environment variables with descriptive names. The above is basically how Armbian boots. Armbian's boot, however, also loads a script-file from the boot-device called 'boot/boot.scr', which first imports environment variables from a file called 'boot/armbianEnv.txt'. This can be both helpful and confusing. Helpful because it makes things work quickly and easily. Confusing if you're trying to change something from your boot-prompt, because you'll keep ending up booting from the same device. Armbian's boot sequence tries to find a bootable device by first probing the SD-card and checking if there's a kernel available there. If not, then it continues to USB. It also supports netboot. This is ideal for someone who does not want to wear out the SD-card slot (they're very fragile, because board vendors very much like to save 3 cents on picking the worst type they can find!) We can also take the load_script environment variable from a few posts earlier ... setenv load_script 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD"; setenv boot_interface mmc; else echo "... booting from USB"; usb start; setenv boot_interface usb; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' .... and expand it and remove the semicolons, so it's a little easier to read ... if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD" setenv boot_interface mmc else echo "... booting from USB" usb start setenv boot_interface usb fi if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr source fi ... then we can add a few modifications to support SATA-boot ... setenv script "boot/boot.scr" if test -e mmc 0:1 $script; then setenv devname SD setenv boot_interface mmc else usb start if test -e usb 0:1 $script; then setenv devname USB setenv boot_interface usb else scsi scan scsi dev 0:1 setenv devname SATA setenv boot_interface scsi fi fi if test -e $boot_interface 0:1 $script; then echo "... booting from $devname" ext4load $boot_interface 0:1 0x00800000 $script source fi ... and finally wrap it back up in one line ... setenv load_script 'setenv script "boot/boot.scr"; if test -e mmc 0:1 $script; then setenv devname SD; setenv boot_interface mmc; else usb start; if test -e usb 0:1 $script; then; setenv devname USB; setenv boot_interface usb; else scsi scan; scsi dev 0:1; setenv devname SATA; setenv boot_interface scsi; fi; fi; if test -e $boot_interface 0:1 $script; then echo "... booting from $devname"; ext4load $boot_interface 0:1 0x00800000 $script; source; fi' ... which is basically what I use for booting from SATA (except from I do not attempt to boot from USB, since I often have my SD-card attached without wanting to boot from it.
  8. I forgot to say that it's on purpose there is no parameter for 'setenv extra_params', because this will 'unset' the variable. One more thing: If you want information about what a command does, try typing this inside Uboot: help booti help ext4ls
  9. I have not seen this string configuration before, it may be the newest way that Armbian starts up - or it may be a default setup for Uboot. It's always a good idea to explore a little before making any changes. The 'for' command iterates through a list of words/strings. First you want to know what's inside "boot_targets" and boot_prefixes... printenv boot_targets boot_prefixes If boot_targets holds a valid list (I'd expect something like 3 words), then take each of those words and supply as parameter for printenv, but prefix them with 'bootcmd_'. Eg. if a string is 'usb' then prefix it with 'bootcmd_usb' because it looks to me like inside the bootcmd, it says 'bootcmd_$target' - something like: printenv bootcmd_usb I do not think the environment variable 'boot_armbian' exists on your board; I likely invented that myself, because I used to switch between the stock ubuntu and Armbian until I got Armbian working on my board. -But I think it's a good idea to check the environment variables that the Armbian booter likely would use... If they're all empty, it means that you'd have to enter them manually. If that's the case, I'd do something like... printenv console get_images set_bootargs load_script get_ramfs kernel_addr ramfs_addr fdt_addr That will print the values of those environment variables. If those environment variables are not empty, you might get away with very little typing, otherwise you may need to 'restore' the entire Armbian boot-setting by hand. Do this following step once only, it saves some of the old setup, in case you want to have a look at it later: setenv orig_bootcmd "$bootcmd" setenv orig_console "$console" saveenv Now, let's try and restore the boot to something that resembles Armbian's usual boot sequence. -Because I like being able to switch boot commands, I'll add an extra level in by adding the 'boot_armbian' variable. Remember that you can verify the values of your environment variables with the 'printenv' command after setenv... setenv console 'console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000' setenv root 'root=/dev/nfs rw' setenv ipaddr '' setenv serverip '' setenv gatewayip '' setenv netmask '' setenv hostname 'marvell' setenv netdev 'eth0' setenv rootpath 'rootpath=/srv/nfs/' setenv extra_params setenv bootcmd 'run boot_armbian' setenv boot_armbian 'run get_images; run set_bootargs; run load_script; booti $kernel_addr $ramfs_addr $fdt_addr' setenv get_images 'tftpboot $kernel_addr $image_name; tftpboot $fdt_addr $fdt_name; run get_ramfs' setenv get_ramfs 'if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x8000000; tftpboot $ramfs_addr $ramfs_name; else setenv ramfs_addr -; fi' setenv set_bootargs 'setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath $extra_params' setenv load_script 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD"; setenv boot_interface mmc; else echo "... booting from USB"; usb start; setenv boot_interface usb; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' setenv kernel_addr '0x5000000' setenv fdt_addr '0x4f00000' setenv image_name 'boot/Image' setenv fdt_name 'dtb' setenv ramfs_name '-' saveenv -As written earlier, 'saveenv' will save your environment variables to SPI-Flash, so after typing 'saveenv' above, wait until you get the "Marvell>>" prompt back; do not do anything before you see the prompt. When you get back the prompt, make sure you have your micro-SD card inserted, then issue the following command: reset -If all goes well your board should start up. If not, I've likely made a typo somewhere, since I've typed all the above by hand, but I've checked each line more than 3 times, to make sure they're all correct - even so, there could still be errors.
  10. -And I haven't even begun yet. I think it's important to understand the details on how the boot-process works. Once you have this knowledge, you'll know much better how to get things working if something gets messed up. The CPU has a small on-chip boot-ROM. In this boot-ROM, there's code that cannot be altered. This code is the code that checks the 3 jumper connections; usually these are set to load the boot-loader from SPI NOR-Flash. If there's something messed up, you'll not get the "Marvell >>" prompt, but instead you'll get a single "> " - still, don't worry if that happens, because there is a way out. When the boot-loader is 'trusted-firmware'-verified, then it is loaded (usually from SPI NOR-Flash as mentioned earlier, but could also be from SATA, UART or eMMC), and finally this boot-loader is executed. The boot-ROM code has now done its job. The bootloader that was just loaded and executed is usually Uboot (it could be anything; even your own code). This bootloader is the one that presents you with the "Marvell >>" prompt and allows you to interrupt the boot-process by pressing for instance space or return. If the bootloader is not interrupted by a keypress within the timeout (usually 2 seconds), then it issues one single command automatically: run bootcmd -This 'bootcmd' is nothing but an environment variable. It contains a string that is executed by Uboot's command-interpreter. You can issue this command to see what's in the variable: printenv bootcmd My 'bootcmd' looks like this: run boot_armbian -Yours might be different. So another environment variable is being executed by the command-interpreter. That environment variable holds instructions on ... 1: Get netboot images - just in case we're netbooting via PXE 2: Setup boot parameters 3: Probe the block devices, in order to find the most likely block-device to boot from (such as MicroSD-card/USB/SATA) Probing is usually done by the 'test' command. A boot-interface and boot-device is chosen (those are usually kept in environment variables) The boot-interface could for instance be "scsi" if you're booting from SATA or "mmc" if you're booting from a MicroSD card 4: Load the kernel image and emergency image (usually done by the ext4load command) 5: Execute kernel image (done by the 'iboot' command). When step 5 is executed, Uboot finished its task and the kernel takes over. If something goes wrong, the emergency disk image is brought up. ... If you at some point are at the "Marvell >>" prompt and want to play around, here's a few things you can try out: If you have a SATA disk connected: scsi scan; scsi dev 0:1 ext4ls scsi 0:1 / If you have a MicroSD card inserted: ext4ls mmc 0:1 / If you have a USB block-device attached: ext4ls usb 0:1 / ext4ls usb 1:1 / The number before the colon is the device number, the number after the colon is the partition. -So if you have your rootfs on partition 12 on your SATA drive, then you could for instance ... ext4ls scsi 0:14 /bin ... to see some of the executable files on that partition. Note: 'scsi scan' probes the SATA interface; you will not be able to do anything useful with the device without issuing that command. You can also set some environment variables if you wish to: setenv myVariable "echo hello there" printenv myVariable echo $myVariable run myVariable You should be able to execute the boot instructions one-by-one until you reach 'iboot'. Let's assume that you've found out how to make your board boot; you've written down all the commands necessary and tested that they indeed boot if you write them exactly as you have them ready (hopefully you have a terminal with copy-and-paste). When you've got your commands tested, you can set the environment variables and save those variables to your SPI-Flash using this command: saveenv Wait for the prompt to return. Make sure you can type on the command-line (thus you will know that the writing is done). After that, you can just boot as usual (either by typing 'boot' or 'reset' or by pressing the reset button). -Do *not* press the reset button while the flash-memory is being written to; that will surely mess up things. At this point, you may have tried some of the above; I expect that you're likely stuck somewhere, if so, please let me know where, so we can get you unstuck.
  11. For anyone who wants to test power consumption, I'll recommend not supplying the board with 12V, but instead 5.2V, which is the minimum voltage required by the voltage regulator. The higher the input voltage, the higher power-loss you'll get. I recommend a good 5.2V PSU, which provides a heavy current like more than 3A. You can use a 6V PSU if you can't find anything lower, but just make sure that it can give the board a lot of current. For keeping power consumption down, I also recommend that you do not use the USB-ports nor the SATA port. That means booting Linux from the microSD card port - or if you want to cheat, you can supply an external harddisk with power from a different PSU and only connect the SATA data cable to the Espressobin. This will result in that the harddisk's power usage does not influence the measurements of the board itself. -And of course, as Thomas says - it's a very good idea shutting down peripherals you do not use. Unfortunately, there are things you can't change. The board has been sprayed with voltage regulators - even nested! I'm convinced that the board could have been designed a little better regarding this. I have not checked if you can shut down some of the power regulators completely, but even if you issue the "poweroff" command, the CPU is still running!! Things to consider: Powering a SATA drive from the board uses a lot of power. A 3.5" drive use much more than a 2.5" drive (check your drive's specs). USB devices use lots of power. MicroSD / MMC uses some power, but it's not extreme. A Mini-PCIe WiFi card uses a lot of power; I'm fairly convinced that the built-in Gbit Ethernet uses less. (unfortunately the Topaz switch has not been utilized very well on the board; it's fairly much a waste, it's just using power without giving extra performance). The DDR RAM uses a fair amount of power, but for good reasons it's not smart to turn it off. ... All those things add on top of the CPU's own power usage, which is said to be 1W. At the moment, I do not have the proper equipment ready for measuring the power usage on the board; but if I find a way, I'll be using a multimeter and a 5.2V power source - and I'll likely be running Armbian from the SD-card or perhaps cheating by running it from a SATA disk with a secondary power supply, so you can easily add your own numbers for the harddisks of your choice.
  12. Thomas, did you get your board up and running again ? -If not, don't worry, it's not as bad as it may seem. I'll be happy to help you get it up and running. Here's a simple overview of what happens during boot: There are two stages: 1: The "Marvell >>" prompt is actually Uboot, the boot-loader. If you haven't updated your boot-loader yet, you can do so from within Uboot, but you need to write the image to either a microSD card or a USB-stick first. When you've updated your boot-loader with the correct version, you can update the boot instructions. (The boot-instructions are actually stored in environment variables). You can experiment with the environment variables manually at no risk of wearing out the flash-memory. If you reboot, those experiments will have to be re-typed, as they're not saved in the SPI-flash. When you're satisfied with your experiments, you can save the environment variables. Normally, Armbian is written to the SD-card's first partition; this partition acts both as the boot partition and as the root file system. (Some linux distributions have boot and rootfs on different partitions). ... I'll be happy to write in further details where needed, but it would likely be too much writing the entire boot process in a single post.
  13. Today I tried to install the latest bionic image; the Armbian_5.59_Espressobin_Ubuntu_bionic_next_4.18.6. The first thing I tried was making a tarball, then writing this tarball to a freshly formatted partition and modifying it. This almost booted with a few tweaks; I was dropped into an emergency shell. I managed to get it running, however, there is no network connection at all; the LED on the network interface stays off. (I did expect that would happen at some point, since that happened with earlier versions after 'apt upgrade'). Not being able to figure out what caused the emergency shell to be invoked, I thought that I'd try installing the tarball on a freshly formatted partition without modifying anything after the installation. That resulted in a never-ending loop of requesting root to change password from 1234 to something else. So I finally gave in and wrote the image to a brand new Sandisk microSD card. I attempted to boot that from USB, but since that didn't work, I moved the card to my microSD card slot. That didn't go well either. I actually forgot what the problem was by now, but it didn't get very far. ... Has the Armbian_5.59_Espressobin_Ubuntu_bionic_next_4.18.6 image been tested on an Espressobin board ? -Did anyone succeed in booting from it yet ? -Anyone got network connection on the board with this new image ?
  14. Found it. You'll need a USB-to-UART adapter, there are plenty of different models on eBay. I very much like CP2102 because there are drivers even for my PowerPC based Macs. -Remember to connect only GND, RxD and TxD. Do not connect VCC. Here's a direct link to the UART debug console page. It also explains the details of the RxD/TxD cross-wiring.
  15. This sounds like that the system on your microSD card is damaged in some way. I have a Cubieboard2 as well and I had to borrow the SD-card for my Espressobin, so I made a backup of the card, then wrote the Espressobin booter, booted the Espressobin and made some installations. When I restored my SD card contents, the Cubieboard2 did not boot from it. Attaching a TFT monitor did not help me either. Here I know for certain that I changed my microSD card is the cause. I very much recommend that you try writing the system to a fresh, unused microSD card (then the chance of getting data-corruption due to wear-out is very small). Note: If your Cubieboard2 was writing logs to your microSD card, this could very likely be a reason that the card is worn out. These days, you should be able to get a real good 90MB/sec 16GB card for $6 (or 5.5 Euro).