Jens Bauer

Members
  • Content Count

    161
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Jens Bauer reacted to thomasgrzybowski in Recovery from espressobin installation mistakes   
    Hi,
     
    I see where this bootcmd comes from - from the espressobin download page here.  I was just tryin' to follow directions.
     
     
    I'll try to follow your directions instead. Tom
     
  2. Like
    Jens Bauer got a reaction from skandalfo in 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.
  3. Like
    Jens Bauer reacted to zador.blood.stained in Clearfog Base with eMMC first boot tutorial   
    Did you add "emmc_fix=on" to /boot/armbianEnv.txt on the eMMC (you needed to mount it after flashing) or did you try to insert a SD card in the microSD slot on the board? Without this eMMC won't be detected by the kernel.
  4. Like
    Jens Bauer reacted to zador.blood.stained in Clearfog Base with eMMC first boot tutorial   
    You can copy it to the same USB stick (as a file) and dd it to the eMMC. Please note that you need to add/set "emmc_fix=on" in /boot/armbianEnv.txt both on your USB stick and on eMMC after you flash the image on it, or you can just insert any SD card into the SD slot.
     
    There is no USB OTG port here so UMS (mass storage gadget) or fastboot is not an option here. The only "better" solution could be tftp based to download the image to RAM or USB storage and flash it to eMMC, but it requires setting up a tftp server, or writing the image from USB to eMMC from u-boot.
  5. Like
    Jens Bauer reacted to zador.blood.stained in Clearfog Base with eMMC first boot tutorial   
    OFF,OFF,ON,ON,ON as per Solid-Run wiki for SD/eMMC. 
  6. Like
    Jens Bauer reacted to zador.blood.stained in Clearfog Base with eMMC first boot tutorial   
    Please try setting switches to OFF,ON,OFF,OFF,ON instead.
     
    I just tried to use kwboot from mainline u-boot and it worked fine for me
    git clone --depth 1 git://git.denx.de/u-boot.git cd u-boot make CROSS_COMPILE=arm-linux-gnueabihf- clearfog_defconfig make CROSS_COMPILE=arm-linux-gnueabihf- tools tools/kwboot -b ~/u-boot-uart.mmc /dev/ttyUSB0 screen /dev/ttyUSB0 115200  
  7. Like
    Jens Bauer reacted to zador.blood.stained in Clearfog Base with eMMC first boot tutorial   
    It may be easier to unpack the .deb package from here than mounting the existing image and extracting files from its filesystem.
     
    Not with PuTTY and I'm not sure if there is a good way to do it from Windows in general.
    I would recommend reading this tutorial and official Solid-Run instructions here.
    You can get the u-boot binary from Armbian packages and this binary can easily boot an image from USB flash with "run usbboot" but you still need to find a way to load the u-boot via UART (either using kwboot or scripts linked in the first tutorial).
     
    It is.
  8. Like
    Jens Bauer reacted to Genesio Lini in Clearfog Base with eMMC first boot tutorial   
    Hello everyone,
    I am trying to achieve first boot with a Clearfog Base with eMMC.
     
    It was not clear (at least to me) that the eMMC version does not allow booting from SD card *at all*
    But hey, let's get this baby up&running, can anybody please help me?
     
    I am trying to follow this procedure [https://www.armbian.com/clearfog-base/]:
    1) Write the image to a USB flash drive
    -> easy enough, I did it with Win32DiskImager and a well-tested 64GB USB stick
     
    2) Load the modified u-boot (from the Armbian image) using the UART method
    -> I have issues here. I suppose that UART method consists in plugging in the microUSB cable into my PC and open the COM3 port with Putty, than hitting some key to interrupt normal boot.
    Unfortunately the terminal just spits out garbled text. The setup for the COM3 port in windows is 9600bps, 8data, no parity, 1 stop, no flow control and matches the config in Putty.
     
    Where do I find the modified u-boot in armbian image?
     
    I'm stuck here, and I don't know how to proceed.
     
    Thank you
    Genesio
  9. Like
    Jens Bauer reacted to Genesio Lini in Clearfog Base with eMMC first boot tutorial   
    I am now trying following steps from here: https://github.com/nightseas/arm_applications/blob/master/doc/getting_started_with_clearfog_base.md#boot-from-usb-disk----download-armbian-to-emmc
    from inside armbian running from the USB stick:
     
    dd'ing the img to the eMMC device was successful:
    root@clearfogbase:~# dd if=/root/Armbian_5.35_Clearfogbase_Ubuntu_xenial_default_4.4.102.img of=/dev/mmcblk0 bs=4M 352+0 records in 352+0 records out 1476395008 bytes (1.5 GB, 1.4 GiB) copied, 79.9802 s, 18.5 MB/s root@clearfogbase:~# sudo mount /dev/mmcblk0p1 /mnt mount: special device /dev/mmcblk0p1 does not exist I was not able to mount the partition in order to modify the armbianEnv.txt.
    But, as I have a uSD card into the slot, I am trying to boot from eMMC anyway.
     
    So I just went on with dd'ing the bootloader to the eMMC:
    root@clearfogbase:~# echo 0 > /sys/block/mmcblk0boot0/force_ro root@clearfogbase:~# echo 0 > /sys/block/mmcblk0boot1/force_ro root@clearfogbase:~# sudo dd if=u-boot.mmc of=/dev/mmcblk0boot0 1836+1 records in 1836+1 records out 940108 bytes (940 kB, 918 KiB) copied, 0.167683 s, 5.6 MB/s root@clearfogbase:~# sudo dd if=u-boot.mmc of=/dev/mmcblk0boot1 1836+1 records in 1836+1 records out 940108 bytes (940 kB, 918 KiB) copied, 0.17947 s, 5.2 MB/s root@clearfogbase:~# echo 1 > /sys/block/mmcblk0boot0/force_ro root@clearfogbase:~# echo 1 > /sys/block/mmcblk0boot1/force_ro root@clearfogbase:~# sync  
    Now I think I could just set the dip switches into eMMC boot position and reboot.
    Is that correct?
  10. Like
    Jens Bauer reacted to Genesio Lini in Clearfog Base with eMMC first boot tutorial   
    Ok, it works.
    after setting the DIP switches to eMMC boot, I rebooted with the uSD card into the slot and armbian was running fine from eMMC.
     
    Then I logged in and modified the armbianEnv.txt
     
    The clearfog now boots from eMMC without uSD card into the slot.
     
    Thank you for your help and patience
     
  11. Like
    Jens Bauer reacted to rothirschtech in Clearfog Base with eMMC first boot tutorial   
    I summarized the content of a few sites and wrote a complete installation guide for Armbian on a Clearfog pro and Clearfog base.

    You will need
    a FAT formatted USB Stick where you can store the Armbian image and some bootloader files an USB A to microUSB B cable Clearfog Base or Pro with a power adapter Prepare installation files
    mkdir -p /opt/clearfog_installation cd /opt/clearfog_installation curl https://wiki.solid-run.com/lib/exe/fetch.php?media=products:a38x:software:debian:clearfog-emmc-v3.tar.gz --output clearfog-emmc-v3.tar.gz tar xfz clearfog-emmc-v3.tar.gz  
    Copy following files to an USB stick
     
    mnt <your usb> /mnt/ mv u-boot-clearfog-base-mmc.kwb zImage armada-388-clearfog.dtb /mnt/ Put Armbian to the stick
    You have to create the _extlinux_ directory and put the _extlinux.conf_ into it. You'll need this do boot a linux image. With it you will be able to write the Armbian image to the eMMC memory
    mkdir -p /mnt/extlinux mv extlinux.conf /mnt/extlinux/ cd /mnt/extlinux/  
    Clearfog Pro
       
    wget https://dl.armbian.com/clearfogpro/Debian_stretch_next.7z Clearfog Base
       
    wget https://dl.armbian.com/clearfogbase/Debian_stretch_next.7z
    Extract and check integrity
    7za e Debian_stretch_next.7z shasum -a 256 -c sha256sum.sha Armbian_*.img STRG+c cd /opt/clearfog_installation umount /mnt  
     
    Next Steps
    Plug in USB stick to the Clearfog Plug in USB cable (USB A site) to the PC Plug in USB cable (microUSB B site) to the Clearfog Set Jumper to UART **0 1 0 0 1**  
    PC
    The maintainer delivers *kwboot* for the installation. With it you can send the u-boot bootloader to the device
       
    ./kwboot -t -b u-boot-clearfog-base-uart.kwb /dev/ttyUSB0  
    Clearfog
    - Power up the Clearfog
    - Wait a few minutes of the U-Boot image to download
    - !! Hit a key to stop autoboot !!
    - Configure the eMMC to boot from hardware boot partition
     
    PC (kwboot terminal)
    mmc partconf 0 1 1 0 date reset run bootcmd_usb0 login with _root_
     
    mount /dev/sda1 /mnt dd if=/mnt/extlinux/Armbian_5.59_Clearfogpro_Debian_stretch_next_4.14.66.img of=/dev/mmcblk0 bs=1M conv=fsync hdparm -z /dev/mmcblk0 umount /mnt/ mount /dev/mmcblk0p1 /mnt/ echo 0 > /sys/block/mmcblk0boot0/force_ro dd if=/mnt/usr/lib/linux-u-boot-next-clearfogpro_5.59_armhf/u-boot.mmc of=/dev/mmcblk0boot0 sed -i 's/emmc_fix=off/emmc_fix=on/g' /mnt/boot/armbianEnv.txt umount /mnt/ poweroff  
    PC (a second terminal)
    killall kwboot screen /dev/ttyUSB0 115200  
    Clearfog
    Unplug power adapter Set jumpers to **0 0 1 1 1** Plugin power jack Now you should see Armbian booting up in the terminal were you executed the _screen_ command

    Sources
    First insights (armbian.com)
    Maintainers installation guide (wiki.solid-run.com)
    First hint for armbian bootloader installation (armbian.com)
    Final Armbian bootloader installation hint
  12. Like
    Jens Bauer reacted to tkaiser in Quick Review of Rock960 Enterprise Edition AKA Ficus   
    Latest RK3399 arrival in the lab. For now just some q&d photographs:
     



     
    @wtarreau my first 96boards thing so far (just like you I felt the standard being directed towards nowhere given that there's no Ethernet). And guess what: 2 x Ethernet here!
     
    A quick preliminary specifications list:
    RK3399 (performing identical to any other RK3399 thingy out there as long as no throttling happens) 2 GB DDR3 RAM (in April Vamrs said they will provide 1GB, 2GB and 4GB variants for $99, $129 and $149) Board size is the standard 160×120 mm 96Boards EE form factor. EE = Enterprise Edition, for details download 96Boards-EE-Specification.pdf (1.1MB) Full size x16 PCIe slot as per EE specs (of course only x4 usable since RK3399 only provides 4 lanes at Gen2 speed) Board can be powered with 12V through barrel plug, 4-pin ATX plug or via pin header (Vamrs sent a 12V/4A PSU with the board) Serial console available via Micro USB (there's an onboard FTDI chip) 2 SATA ports + 2 SATA power ports (5V/12V). SATA is provided by a JMS561 USB3 SATA bridge that can operate in some silly RAID modes or PM mode (with spinning rust this chip is totally sufficient -- for SSDs better use NVMe/PCIe) Socketed eMMC and mechanical SD card adapter available (Vamrs sent also a SanDisk 8GB eMMC module as can be seen on the pictures) SIM card slot on the lower PCB side to be combined with an USB based WWAN modem in the mPCIe slot (USB2 only) 1 x SD card slot routed to RK3399, 1 x SD card slot for the BMC (Baseboard Management Controller) Gigabit Ethernet and separate Fast Ethernet port for the BMC Ampak AP6354 (dual-band and dual-antenna WiFi + BT 4.1) USB-C port with USB3 SuperSpeed and DisplayPort available eDP and HDMI 2.0 USB2 on pin headers and 2 type A receptacles all behind an internal USB2 hub USB3 on one pin header and 2 type A receptacles all behind an internal USB3 hub 96boards Low Speed Expansion connector with various interfaces exposed 96boards High Speed Expansion connector with various interfaces exposed (e.g. the 2nd USB2 host port, see diagram below) S/PDIF audio out 'real' on/off switch to cut power. To really power on the board the translucent button next to it needs to be pressed  

  13. Like
    Jens Bauer got a reaction from tkaiser in 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.
  14. Like
    Jens Bauer got a reaction from tkaiser in 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.
  15. Like
    Jens Bauer reacted to skandalfo in Espressobin: rescue instruction for macronix SPI chip   
    Not enough. The recovery image is loaded to RAM only, so when you reset it goes away and you boot again from a borked image once jumpers are back to normal.
     
    What you need to do is use the image in RAM you just booted from to flash a good one to SPI.
     
    After WtpDownload finishes, going back to the serial terminal and pressing enter a couple of times should give you a working uboot prompt (with your UART image that now can write to your flash). From there you should be able to use the bubt command like explained here, or some other of the commands in that page to make your changes permanent.
  16. Like
    Jens Bauer reacted to skandalfo in Espressobin: rescue instruction for macronix SPI chip   
    So, I just checked that I could use the images in this folder to flash the current ones in its grand-parent one, and that I still was able to boot from the Armbian already installed in my SD card with a Macronix chip. Thanks a lot for these fixed images! 
     
    Steps:
    Had to use miniterm: miniterm --eol CR /dev/ttyUSB0 115200 rather than minicom. Minicom would interfere with the transfer from WtpDownload by trying to reopen the serial port once it had lost it; and then WtpDownload_linux would get interrupted. Set the jumpers for UART recovery and powered the board. In miniterm I hit enter until I got the E prompt, then entered "wtp". Then I ran the upload:  <path>/<to>/WtpDownload_linux -P UART -C 0 -R 115200 -B TIM_ATF.bin -I wtmi_h.bin -I boot-image_h.bin -E  
    As my bootable SD card was in, the just-downloaded bootloader in RAM would quickly go and start Linux from the SD card. If your EspressoBIN is borked, you probably should just remove any boot device. In my case I didn't bother; I just restarted miniterm quickly after WtpDownload had finished and pressed enter a number of times to interrupt the boot sequence.
    I plugged in a USB stick with flash-image-2g-2cs-1000_800.bin in it.
    I flashed it to SPI:
    Marvell>> bubt flash-image-2g-2cs-1000_800.bin spi usb Burning U-BOOT image "flash-image-2g-2cs-1000_800.bin" from "usb" to "spi" USB0:   Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1:   USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 2 USB Device(s) found reading flash-image-2g-2cs-1000_800.bin Image checksum...OK! SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB     Updating, 8% 126859 B/s    Updating, 16% 127704 B/s    Updating, 31% 167458 B/s    Updating, 39% 155994 B/s 262144 bytes written, 593344 bytes skipped in 2.249s, speed 389342 B/s Done! I then powered the board off, switched the boot jumpers back to their default position, and powered it on again. The board booted Armbian from SD card as usual.
     
  17. Like
    Jens Bauer reacted to giri@nwrk.biz in Armbian build environment in chroot jail   
    Probably the easiest and fastest way to set up an Ubuntu Xenial build environment (needed by the armbian build scripts) is using a chroot jail. This thread should be a quick copy paste "tutorial" to create your own chroot jail and on an Debian based linux installation.
     
    1.) Install debootstrap
    $ sudo apt install debootstrap  
    2.) Chreate chroot jail using debootstrap
    $ sudo debootstrap --variant=buildd --arch=amd64 xenial ./system/ http://archive.ubuntu.com/ubuntu/  
    3.) Mount your local system into the chroot
    $ for f in dev dev/pts proc sys ; do sudo mount -o bind /$f ./system/$f ; done 4.) Mount resolv.conf from host system into chroot
    $ sudo mount --bind /etc/resolv.conf ./system/etc/resolv.conf  
    5.) Enter the chroot and install some important packages
    $ sudo chroot ./system $ apt install -y sudo nano git 6.) Add universe to your chroots repo list (needed by the build scripts)
    $ sudo nano /etc/apt/sources.list change from: deb http://archive.ubuntu.com/ubuntu xenial main to: deb http://archive.ubuntu.com/ubuntu xenial main universe then: $ sudo apt update 7.) Download and start build script in root users home directory
    $ cd $ git clone https://github.com/armbian/build $ cd build $ service apt-cacher-ng start ( $ export EXPERT=yes ) $ ./compile.sh Now you can start building your images from source
    I know this is not rocket science, but I think this might help some people getting into Armbian!
  18. Like
    Jens Bauer reacted to botfap in Armbian build farm   
    UK Server deployed. Details PM'd
  19. Like
    Jens Bauer reacted to Igor in MMC: No card present error on Allwinner boards   
    https://forum.armbian.com/index.php?/topic/3945-mmc-no-card-present-error-on-allwinner-boards
     
  20. Like
    Jens Bauer reacted to Igor in Armbian torrents - lots of disk space ?   
    It should be 378. It's some time since 60GB was set  Everything is fine. Many new boards and Bionic as a test option on some ... with some cleaning and with some additional logic, this could be brought down. But its some work.
  21. Like
    Jens Bauer got a reaction from tkaiser in EspressoBIN - Bionic feedback   
    This is how I've currently set up my u-boot:
    setenv bootcmd 'run boot_armbian' setenv boot_armbian 'run get_images; run set_bootargs; run load_script2; booti $kernel_addr $ramfs_addr $fdt_addr' setenv get_images 'tftpboot $kernel_addr $image_name; tftpboot $ftd_addr $ftd_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_script2 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD-card"; setenv boot_interface mmc; else echo "booting from SATA"; scsi scan; setenv boot_interface scsi; scsi dev 0:1; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' # A suggested, but untested SATA-boot (try MMC first, then USB, then SATA): setenv load_script3 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD-card"; setenv boot_interface mmc; else usb start; if test -e usb 0:1 boot/boot.scr; then echo "... booting from USB"; setenv boot_interface usb; else echo "booting from SATA"; setenv boot_interface scsi; scsi scan; scsi dev 0:1; fi; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' There might be typos, because I don't have any copy-and-paste from my serial terminal and in addition, load_script3 has not been tested, so it may contain errors as well.
    -But you should get the idea; it's in fact just a tiny addition to armbian's default setup.
  22. Like
    Jens Bauer got a reaction from tkaiser in EspressoBIN - Bionic feedback   
    I've set up my local EspressoBIN with 18.04 Bionic (Armbian_5.44_Espressobin_Ubuntu_bionic_next_4.14.40.7z).
     
    My impression is that it's very much like setting up Xenial and the same issues seem to be present.
    I mention them in the order of importance.
    1: #reboot sometimes hang, so does #poweroff. It would be great to get this fixed, because it would be a disaster if a device hangs on rebooting from remote (eg. the device is 200km away).
    2: sudo apt-get update && sudo apt-get upgrade destroys the network setup. No network access is possible after doing this. I think a fix is important, because people would likely issue those commands.
    3: Network seem to be configured slightly different than on Xenial; it seems I cannot configure a static IP on the WAN port (see my other post specifically on static IP). For now, I'll be using a static IP address on the br0, this works, so it's not the highest priority.
     
    I definitely also need to write some good stuff.
     
    1: 3Gbit JMB321 Port Multipliers work well with Xenial (and likely also Bionic); just remember to connect the boot device to SATA0 and there should be no problems.
    2: 6Gbit JMB575 (StarTech) works great with Bionic (and likely also Xenial); again connect the boot device to SATA0.
     
     
    For those, who want to boot "directly" from SATA, this is what I do on both boards; it's fairly easy and there are plenty of ways you can do it.
    The first time, I just made a 'dd' from my SD-card's partition to my harddisk's partition. This works fine and the partition will be expanded when Armbian boots.
    My preferred way, though, is to make a tarball of the unmodified SD-image's partition, boot my EspressoBIN from the SD-card and extract the files onto my desired partition. This gives me a different UUID from the SD-card, thus inserting the Armbian SD card won't confuse my boot-up sequence.
     
    To create a tarball, this can be used (mounted as /mnt/sd) ...
    cd /mnt/sd && sudo tar -cpzf /data/armbian-bionic-rootfs.tar.gz .
     
    To extract onto your partition (mounted as /mnt/rootfs), this can be used ...
    cd /mnt/rootfs && sudo tar -xpzf /data/armbian-bionic-rootfs.tar.gz -C .
     
    Those will preserve permissions, timestamps and other attributes as necessary, but this will only happen if you're root, otherwise permissions will be messed up and you'll get a half-working system (quite useless).
     
    I use a custom UUID on my own setup, so that I only need to set it once in u-boot. I highly recommend using UUID for identifying the boot device, especially is you use a port multiplier, because you never know if a USB-drive suddenly get /dev/sda instead of the drive you expect.
     
    In your startup boot sequence, I recommend a 3-stage check ...
    1: Check for SD-card (SD/MMC slot)
    2: Check for USB-boot
    3: Use a 'scsi scan; scsi dev $bootdev:$bootpart;' then check for your SATA-device here.
     
    Personally I only have step 1 and 3, since I often mount my SD-card as a USB-drive when I do not want to boot from it.
  23. Like
    Jens Bauer reacted to Tazz in Espressobin support development efforts   
    For those who want to run at 1.2ghz, if you have not noticed you need this:
    https://marc.info/?l=linux-arm-kernel&m=152941191324122&w=2
  24. Like
    Jens Bauer reacted to Igor in Espressobin support development efforts   
    apt update & upgrade will also do
    https://github.com/armbian/upload/commit/553477df85dfdd33810d1536409d62bd3a4cb789
     
    Thanks.
  25. Like
    Jens Bauer got a reaction from arm-push in 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.