New patches for mainline u-boot have been posted, so that espressobin should finally work now.
That gives us a recent version of u-boot, compared to that old and unmaintained marvell fork.
I opened a PR for OpenWRT to ship mainline u-boot/atf builds. Those include distro boot: openwrt/openwrt#3360
Yes I have a v5 with 2 GiB RAM and 8 MB of Flash (from the original KickStarter campaign). It would likely take me a day or two to locate it as it is still in packing boxes in my garage from my move a year ago! I also have a v7 with 1 GiB RAM.
Sorry, I meant 4MB NOR flash. I created the wikidevi entry from my device shortly after it arrived from the original KickStarter campaign. I later acquired a V7 unit and created the corresponding wikidevi page.
Do I understand correctly that we should better update/flash uboot before booting 21.02? and this uboot may boot openwrt as well as other distros (eg armbian)?
Also, could you please clarify about the uart image residing here? Is this the uart rescue option?
Thank you
This seems perfect. If I understand well, I could flash the new uboot remotely and if successful, I could install remotely openwrt 21.2 on an already installed hard drive and set the boot priority to the hard drive first from the environment. This way I could dual boot remotely if needed. What I am missing is the jumpers and the environment.
Do I need to touch the jumpers?
Regarding the environment, I paste below the current env of my v5 espressobin.
I see here your environment which is really different and also what armbian is proposing.
As I have very little experience on this, which one should I follow as default environment?
Thank you
No need to change... Only needed in case of "recovery mode" !
Prefer the default OpenWrt script...
Mainly, after an uboot upgrade, you only need to change/write back the ethaddr value which is your Network Ethernet Mac Address.
The GOOD procedure for UBoot upgrade will be something like ;
0. have a good bootcmd and env settings, with a backup of fw_env. and healthy OpenWrt.
upgrade uboot (from OpenWrt or directly from UBoot)
here normally you need to reboot to UBoot and set the default env value ! (depends of the from/to UBoot versions)
restore the needed env, like ethaddr (must be sufficient, you may tweak the boot order if needed with the boot_targets env value)
boot to your system (again)
backup, tweaks, play...
The same procedure for OpenWrt upgrade will be explained here :
Mainly like :
0. had a backup of configs
had a backup of installed packages (I recommend Opkgs extras and hotplug extras bit take care that depending of the extroot or overlay, you can "auto" broke your system !)
sysupgrade with keeping, when possible, the configs
if needed, reset you extroot/overlay (manually, I have some script still in development for this...)
reinstall package (or let hotplug & opkg extras do it for you automatically)
It is a lot of "I cross my finger" in near each steps !
In a remote way it more than this, but it can be a game to play...
Always think about needing to get a trip to the device.
Always think about needing to do a recovery of the device.
Some steps could be automated/scripted, it is done on commercials products based on OpenWrt, but I never seen any share of their methods.
I am studying some based of my own experiences, from years now, but they are still not perfect enough, and you can see topics on the forum about discussion on this particular subject !
Thank you.
I know it is dangerous. If uboot needs the ethernet MAC (in a sense that it does not apply a random one) then remote uboot upgrade is a no-go. But I will probably test that when I will be onsite by the device.
About OpenWrt, I had in mind a clean installation of 21.02 on the hard disk (19.07 is working on the sd card now). I have access to espressobin from other local devices in case of failure and I have already done this with turris omnia and turris os and all went fine. I was even able to set the lan ip before booting into it!!
The main problem is with an upgrade of a different version of uboot, where the env address may move...
You can do a pseudo reset of the env with the backup of another device...
We may also tweak the ethaddr reset with a uboot env which set it ?!
All is possible but mainly untested.
The difficult points are to script some steps...
If you give a try, I will be interested by your feedback !
Thanks, I did not know this feature.
Then you may only need to change the boot_targets order.
These env have been tested with IPFire, OPNSense, Debian, ARMBian, OpenWrt...
Some works also fine in UEFI mode !
They are from the mainline DENX u-Boot...
May be they were a little modified with some personal tweak (like FDT name and ETHADDR).
OpenWrt boot.scr from the Firmware itself, will also tweak some parts.
Here boot.scr content from my 21.02.0 EBIN-Ultra
root@OpenWrt:/# mount /dev/mmcblk0p1 /boot/
[ 450.444499] EXT4-fs (mmcblk0p1): mounted filesystem without journal. Opts: (null)
root@OpenWrt:/# strings /boot/boot.scr
Vpic
# Bootscript for Globalscale ESPRESSOBin Board
# Set distro variables if necessary for compability with downstream firmware
if test -z "${kernel_addr_r}"; then
setenv kernel_addr_r 0x7000000
if test -z "${fdt_add_r}"; then
setenv fdt_addr_r 0x6f00000
if test -z "${devtype}"; then
setenv devtype mmc
if test -z "${devnum}"; then
if mmc dev 0; then
setenv devnum 0
elif mmc dev 1; then
setenv devnum 1
# figure out partition uuid to pass to the kernel as root=
part uuid ${devtype} ${devnum}:2 uuid
setenv console "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
setenv bootargs "root=PARTUUID=${uuid} rw rootwait ${console}"
echo "Booting Linux from ${devtype} ${devnum} with args: ${bootargs}"
load ${devtype} ${devnum}:1 ${fdt_addr_r} armada-3720-espressobin-ultra.dtb
load ${devtype} ${devnum}:1 ${kernel_addr_r} Image
booti ${kernel_addr_r} - ${fdt_addr_r}
as you can see the mmc boot is "hardcoded" in the boot.scr !
So you also need to tweak it for hard drive boot (IDE, USB, ...)
Sorry, I misread this...
If there is now ethaddr env sets in uboot, the recent u-boot now get a random one.