Jens Bauer

Members
  • Content Count

    158
  • Joined

  • Last visited

1 Follower

About Jens Bauer

  • Rank
    Elite member

Profile Information

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

Recent Profile Visitors

891 profile views
  1. Jens Bauer

    Daily (tech related) news diet

    ... 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.
  2. Jens Bauer

    Daily (tech related) news diet

    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.
  3. Jens Bauer

    Daily (tech related) news diet

    Did you read about this security hack ? (Bloomberg)
  4. Jens Bauer

    Recovery from espressobin installation mistakes

    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.
  5. Jens Bauer

    Recovery from espressobin installation mistakes

    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
  6. Jens Bauer

    Recovery from espressobin installation mistakes

    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 '0.0.0.0' setenv serverip '0.0.0.0' setenv gatewayip '10.4.50.254' setenv netmask '255.255.255.0' 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.
  7. Jens Bauer

    Recovery from espressobin installation mistakes

    -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.
  8. Jens Bauer

    espressobin power consumption

    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.
  9. Jens Bauer

    Recovery from espressobin installation mistakes

    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.
  10. Jens Bauer

    EspressoBIN - Bionic feedback

    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 ?
  11. Jens Bauer

    Diagnosing failure to boot in Cubieboard 2

    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.
  12. Jens Bauer

    Diagnosing failure to boot in Cubieboard 2

    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).
  13. Jens Bauer

    EspressoBIN - Bionic feedback

    I've gotten a little further with finding out what makes "apt upgrade" stop working on the Espressobin (this likely applies to both Bionic and Xenial). As soon as I boot Bionic, I see that 2 upgrades are available, before I issue 'apt update'. I can safely issue 'apt upgrade' without first issuing 'apt update'! After rebooting, network is still online. If I then do an 'apt update' followed by 'apt upgrade apt' (eg. only the first upgradable item in the list), I lose network when setting up systemd ... -So far, so good; I'll try and see how many packages can be upgraded without losing network; so for now I'll try avoiding upgrading systemd. I've also noticed that both 'poweroff' and 'reboot' hangs here ... I've begun using these instead of 'reboot' and 'poweroff'; I have not experienced that they hang yet: sudo systemctl poweroff sudo systemctl reboot I'm successfully running the following on both Bionic and Xenial: Redis (3 instances) Git+gitolite+gitweb (11 different locations, 11 x gitweb too) with login on port 9418 NFS Netatalk-3.1.11 Nginx-1.14.0 with the horrible fcgicrap GeoIPLite2 with CPAN modules Transmission (for Armbian torrents) Archivemount, unar, unzip Unbound Disabled RAM logging (since I run on SATA) Disabled unattended upgrades (since I'm running the boards as servers) BTRFS on all partitions except from the boot and root partitions 200+ web sites with CGI-scripts (ported from Apache in less than a week) - much more responsive than Apache2 on my Mac Mini Note: If running Redis-server 4.0.11, the CPAN module will not build, due to that some strings have been changed in Redis. The easy fix is to install redis-server-4.0.10 and then install the CPAN module. This also means that you should not upgrade Redis after that. On Xenial, I was able to build and run my own version of cfgiwrap, but on Bionic, I've made several attempts and can not get it to work - even if I manually just replace the binary and nothing else. I've tried downloading different versions of fcgiwrap (even from Ubuntu/Bionic), but no dice so far. It's likely I'll be building and installing qmail next - I had to upgrade the TLS code, since Bionic comes with OpenSSL-1.1.0, which means the currently available code and patches fail.
  14. Jens Bauer

    Armbian torrents - lots of disk space ?

    OK, I'll probably make a simple systemd service that logs disk-space or something and send me an email if a high-watermark is reached. :)
  15. For anyone coming across this: Removing the symlink didn't work for me on Espressobin, but the following did: systemctl stop serial-getty@ttyS0.service