Installing openwrt-18.06 on espressobin

Trying to use the sdcard image from snapshots for the espressobin and am not quite sure how to get it to work. Writing the image with dd (I think) breaks a load of symlinks as, on boot, the kernel cant locate an init system and when extracting with 7zip the inner images of the disk image for partition two (root partition) show symlinks broken when extracted. Not sure how to get it to work and some help would be nice

Which U-Boot version do you have on your espressobin?

Currently on U-Boot 2017.03-armada-17.10.2-g14aeedc which came stock on the device.

I got it working on mine.

I extracted the .img file from openwrt-18.06.0-mvebu-cortexa53-globalscale-espressobin-ext4-sdcard.img.gz, then used Etcher to write the .img file to the SD card (though dd should work too).

The partitions didn't fill the card, so I used Gparted to expand the main partition to the rest of the card.

Then, put the card back in the espressobin, and connect to it over serial as it boots up to get to the U-Boot prompt. Follow the instructions here for setting the boot parameters, except the following lines:

setenv fdt_name 'boot/armada-3720-community.dtb'
setenv image_name 'boot/openwrt-armada-ESPRESSObin-Image'

should actually be...

setenv fdt_name '/armada-3720-community.dtb'
setenv image_name '/Image'

And in the "bootmmc" and "bootcmd" setting commands listed, change:

root=/dev/mmcblk0p1

to

root=/dev/mmcblk0p2

...since the root filesystem is on the second partition.

I had to combine your instructions, the addresses from the Armbian Linux install instructions, and used 18.06.1 install. Was also able to resize the 2nd partition using a mix of parted & resize2fs.

env default -a
setenv ethact 'neta0'
setenv fdt_name 'armada-3720-espressobin.dtb'
setenv image_name 'Image'
setenv bootmmc 'mmc dev 0; ext4load mmc 0:1 0x7000000 Image;ext4load mmc 0:1 0x6000000 armada-3720-espressobin.dtb;setenv bootargs $console root=/dev/mmcblk0p2 rw rootwait; booti 0x7000000 - 0x6000000'
setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 0x7000000 Image;ext4load mmc 0:1 0x6000000 armada-3720-espressobin.dtb;setenv bootargs $console root=/dev/mmcblk0p2 rw rootwait; booti 0x7000000 - 0x6000000'
saveenv

I followed your U-boot settings and I all I got was:

[    1.927006] Marvell 88E6390 !soc!internal-regs@d0000000!mdio@32004!switch0@1!mdio:13: attached PHY driver [Marvell 88E6390] (mii_bus:phy_addr=!soc!internal-regs@d0000000!mdio@32004!switch0@1!mdio:13, irq=POLL)
[    1.947148] xenon-sdhci d00d0000.sdhci: Got CD GPIO
[    2.015177] genirq: Setting trigger mode 3 for irq 35 failed (0xffffff80082f74a0)
[    2.022496] mmc0: SDHCI controller on d00d0000.sdhci [d00d0000.sdhci] using ADMA
[    2.030824] hctosys: unable to open rtc device (rtc0)
[    2.038694] Waiting for root device /dev/mmcblk0p2...

Any ideas?

Please, let me know.

Looks like its having trouble pulling the OS from the 2nd partition on the card. (ponders) Double check you have two working ext partitions on the card; e2fsck might be the quickest validation.

Thanks for replying it.

I updated to the latest firmware from Armbian, from early September. And, It didn't help either.

Capturar%20SD

I even changed SD Cards. Above it what parted tells me about this card.

e2fsck checked the filesystem. Encountered some errors but that was it.

I can boot. Let's make that clear. The problem is when I resize the second partition in order to fill all remaining disk

The below is the state of my screen for the last 2 hours.

_set_type+0x0/0xe0)
[ 2.013836] mmc0: SDHCI controller on d00d0000.sdhci [d00d0000.sdhci] using ADMA
[ 2.022084] hctosys: unable to open rtc device (rtc0)
[ 2.028967] Waiting for root device PARTUUID=15374738-02...
[ 2.127543] mmc0: new ultra high speed SDR104 SDHC card at address aaaa
[ 2.134645] mmcblk0: mmc0:aaaa SC16G 14.8 GiB
[ 2.143813] mmcblk0: p1 p2
[ 210.125177] random: crng init done

I'm stuck.

PS: Forgot to mention that Parted, e2fsck were all made using an external SD card reader connected to my Raspberry Pi running OSMC.

Hi There,
I extracted the .img file from openwrt-18.06.0-mvebu-cortexa53-globalscale-espressobin-ext4-sdcard.img.gz ,using 7zip, then used Etcher on Windows to write the .img file to the SD card.

Then I changed:
Marvell>>
setenv bootmmc 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=/dev/mmcblk0p2 rw rootwait; booti $kernel_addr - $fdt_addr'
setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=/dev/mmcblk0p2 rw rootwait; booti $kernel_addr - $fdt_addr'
setenv fdt_name '/armada-3720-espressobin.dtb'
setenv image_name '/Image'
saveenv
run bootmmc

And it's now booting very well.

1 Like

The problem in Your case is that when You change the size of a partition, it's not the only thing that changes. When it's performed also new PARTUUID is assigned, and that is the root cause for stalled boot. To check this You can use blkid.

You'll have to manually rewrite PARTUUID to desired one, or recreate boot.src with new PARTUUID. There's also possibility to use imagebuilder to create proper new image with desired size. Before creating image, edit CONFIG_TARGET_ROOTFS_PARTSIZE= in .config file. The size provided should be in MB, don't forget to leave ~100MB for bootfs partition.

Ok I understand what you are saying but I'm still a bit new to this so. How would I go about expanding the partition?
Option 1 : Manually rewrite the partition
Where/how would I do that?
Option 2: Recreate boot.src
How would I go about that?
Option3: use Image builder
Is that way more advance? Would that be the best option?
How would I do that?

Now you don't need to go in the needy greety if you don't want,general steps and google will help me do the rest :wink:

I replied to Hbbs, but TBF this affects everybody that wants to expand partition.

Add. 1
Not to rewrite the partition but the MBR. To rewrite it You'll need hex editor for that, never done that myself.
You do that after partition expanding.
Add. 2
If You followed the instructions in commit introducing ESPRESSObin, U-Boot searches in the first partition on SD card for small boot script named boot.scr. In this script there are few commands for U-Boot itself to execute and few options passed to kernel (one of them is PARTUUID). The script is viewable by any text editor but it embeds also a checksum, so if You'll change it, without adding proper checksum, U-Boot will complain that it's invalid. To generate proper script, You feed plain script file to mkimage which is part of uboot-tools (may be that it's called different in Your distro).
This is also done after partition expanding.
Add. 3
It's the easiest one (my biased opinion). Download the image builder from the same download directory as the SD card image for ESPRESSObin. Unpack, edit .config file like i mentioned in previous post, and build the image (for available commands run make help, more generic infos: https://openwrt.org/docs/guide-user/additional-software/imagebuilder). Write resulted image to SD card and enjoy.

For reference I'll point to location in git tree which holds the code responsible for creating original SD card images:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/mvebu/image

1 Like

Tried the imagebuilder from the latest release.

Collected errors:
 * opkg_install_cmd: Cannot install package mwlwifi-firmware-88w8864.
 * opkg_install_cmd: Cannot install package mwlwifi-firmware-88w8964.
Makefile:149: recipe for target 'package_install' failed
make[2]: *** [package_install] Error 255
Makefile:108: recipe for target '_call_image' failed
make[1]: *** [_call_image] Error 2
Makefile:192: recipe for target 'image' failed
make: *** [image] Error 2

This is a nightmare.

I really don't know why the maintainer of the espressobin images could not add an expand filesystem option just like Raspbian does.

I was able to successfully create a custom image ROOTFS to fill a 64GB SD card with your instructions. Thanks. Now I would like to find the OPTION to expand the filesystem instead of creating these unruly images. Had to create a virtual disk image twice the size of the image I wanted to create just to avoid write failures. Any thoughts?

I had same error. Need to be specific on the profile.

First download the latest imagebuilder from the source to avoid collected errors.

Then try the following from the imagebuilder folder after you edit the .config file that is hidden:

make image PROFILE=globalscale-espressobin

Hope it works.

I really like OpenWRT from the user end rather than the Linux experiment and compile end, and I'm a Linux user only to the extent of what I see in Windows PuTTY and WinSCP. So I am sitting here with an Espressobin V5 and a 16G super fast SD. Is there currently a shorter route to get the my V5 up and running? Thanks!

***** Anyone willing to share how to easily build a 16GB SD card using Windows so I can boot this machine and get started? I am a long-time OpenWRT fan but only use the basic plug and play in the past (and thanks to the countless who have brought it to this level for those of us who struggle with the constant changes in technology)

Espressobin was incidentally suggested to me here in the OpenWRT forum to use as a network drive server. I know I could likely spend hundreds of dollars on one of the new routers that look like an alien space pod with 20 antennas on them but this was presented to me in another post by the OpenWRT community as an economical NFS solution and I am anxious to get started. I'd like to simply use a Windows utility to burn a SD card but I am guessing from above it's not that simple.

I think you can burn an SD card from either the first or third image:

https://downloads.openwrt.org/releases/18.06.2/targets/mvebu/cortexa53/

using a tool I'll look up... hold on

On Windows. This is the tool that Armbian recommends, and it worked well for me installing Armbian. It verifies the write after writing, which is important.

The ext4 image will not have that "revert to stock" option that you're used to with OpenWrt, but the squashfs will... On the other hand, if you want to revert to stock, you can always yank the card and reflash the image. So I'd recommend the ext4 version.

Armbian guys said it was a must do to upgrade the uboot. Does anyone here have opinions on that?

I am not subscribed to this and missed your comment. Thanks for providing it. What I have done up to this moment is to use Win32diskimager to build the 16GB very fast SD card. I followed instructions online to install the PL2303 drivers and when I plugged in the board, I was assigned COM4 (unique to each install) and then I configured PuTTY for a SERIAL connection to COM4 (seen from Windows Device Manager, Com ports) at a speed of 115200 and then I powered on the device and I received this. I am not sure what this says, maybe it says that the card image is no good???

I took the file:
openwrt-18.06.2-mvebu-cortexa53-globalscale-espressobin-ext4-sdcard.img.gz
and I unzipped it with WinRAR to:
openwrt-18.06.2-mvebu-cortexa53-globalscale-espressobin-ext4-sdcard.img

and I burned this to the SD card with Win32DiskImage

Here is the console that I received:

Marvell>> TIM-1.0
WTMI-armada-17.10.5-bb8f823
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.155V

Fill memory before self refresh...done

Fill memory before self refresh...done

Now in Self-refresh Mode
Restore termination values to original values
Exited self-refresh ...


Self refresh Pass.
DDR self test mode test done!!

Self refresh Pass.
DDR self test mode test done!!

QS GATING
=============
Calibration done: cycle = 0x00 tap =0x5D
CH0_PHY_RL_Control_CS0_B0[0xC0001180]: 0x0000005D
CH0_PHY_RL_Control_CS0_B1[0xC0001184]: 0x0000005D


QS GATING
=============
Calibration done: cycle = 0x00 tap =0x5B
CH0_PHY_RL_Control_CS1_B0[0xC00011A4]: 0x0000005B
CH0_PHY_RL_Control_CS1_B1[0xC00011A8]: 0x0000005B

DLL TUNING
==============
   DLL 0xc0001050[21:16]: [0,2e,17]
   DLL 0xc0001050[29:24]: [4,33,1b]
   DLL 0xc0001054[21:16]: [0,2c,16]
   DLL 0xc0001054[29:24]: [8,34,1e]
   DLL 0xc0001074[21:16]: [0,3f,1f]
   DLL 0xc0001074NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.3(release):armada-17.10.3:39a62a1
NOTICE:  BL1: Built : 15:39:52, Jun  1 2NOTICE:  BL2: v1.3(release):armada-17.10.3:39a62a1
NOTICE:  BL2: Built : 15:39:54, Jun  1 2018NOTICE:  BL31: v1.3(release):armada-17.10.3:39a62a1
NOTICE:  BL31:

U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - 15:39:10 +0800)

Model: Marvell Armada 3720 Community Board ESPRESSOBin
       CPU    @ 1000 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
DRAM:  1 GiB
U-Boot DT blob at : 000000003f7161b8
Comphy-0: USB3          5 Gbps
Comphy-1: PEX0          2.5 Gbps
Comphy-2: SATA0         6 Gbps
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIE-0: Link down
MMC:   sdhci@d0000: 0, sdhci@d8000: 1
SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
** File not found boot/Image **
** File not found boot/armada-3720-community-v5.dtb **
Bad Linux ARM64 Image magic!
Marvell>>

(((( Thank you!))))

OK I downloaded Balena Etcher and flashed the same file to the SD card. This time the boot sequence went forward but it paused for a moment to see if I wanted to stop autoboot but then it kept on going. Here is my console output:

Marvell>> TIM-1.0
WTMI-armada-17.10.5-bb8f823
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.155V

Fill memory before self refresh...done

Fill memory before self refresh...done

Now in Self-refresh Mode
Restore termination values to original values
Exited self-refresh ...


Self refresh Pass.
DDR self test mode test done!!

Self refresh Pass.
DDR self test mode test done!!

QS GATING
=============
Calibration done: cycle = 0x00 tap =0x5D
CH0_PHY_RL_Control_CS0_B0[0xC0001180]: 0x0000005D
CH0_PHY_RL_Control_CS0_B1[0xC0001184]: 0x0000005D


QS GATING
=============
Calibration done: cycle = 0x00 tap =0x5B
CH0_PHY_RL_Control_CS1_B0[0xC00011A4]: 0x0000005B
CH0_PHY_RL_Control_CS1_B1[0xC00011A8]: 0x0000005B

DLL TUNING
==============
   DLL 0xc0001050[21:16]: [0,2d,16]
   DLL 0xc0001050[29:24]: [4,33,1b]
   DLL 0xc0001054[21:16]: [0,2b,15]
   DLL 0xc0001054[29:24]: [8,34,1e]
   DLL 0xc0001074[21:16]: [0,3f,1f]
   DLL 0xc0001074NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.3(release):armada-17.10.3:39a62a1
NOTICE:  BL1: Built : 15:39:52, Jun  1 2NOTICE:  BL2: v1.3(release):armada-17.10.3:39a62a1
NOTICE:  BL2: Built : 15:39:54, Jun  1 2018NOTICE:  BL31: v1.3(release):armada-17.10.3:39a62a1
NOTICE:  BL31:

U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - 15:39:10 +0800)

Model: Marvell Armada 3720 Community Board ESPRESSOBin
       CPU    @ 1000 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
DRAM:  1 GiB
U-Boot DT blob at : 000000003f7161b8
Comphy-0: USB3          5 Gbps
Comphy-1: PEX0          2.5 Gbps
Comphy-2: SATA0         6 Gbps
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIE-0: Link down
MMC:   sdhci@d0000: 0, sdhci@d8000: 1
SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
** File not found boot/Image **
** File not found boot/armada-3720-community-v5.dtb **
Bad Linux ARM64 Image magic!
Marvell>>