Hi,
A bit of fun, but I now have OpenWrt running on my ESPRESSObin device - quite like it, and it works well. But ... how to "sysupgrade", when OpenWrt is installed on a USB drive? There doesn't seem to be a sysupgrade option, and I don't want to have to take the device apart ever time I want to upgrade the OS.
Thanks!
Well...you could always dump the contents of the usb drive for backup before any upgrade so you can easily restore it.
Yep, just a bit painful 
. OK, I inserted and installed to the MicroSD ... but even then, no sysupgrade? That one is a bit odd to me 
Thanks!
What do You mean "no sysupgrade"? The sdcard image is also sysupgrade image.
Yep, but it complains about compatibility. I can force it, but not sure that's right. Or ... as I installed like ESPRESSObin notes, perhaps that's not quite right?
Thanks!
FYI, when trying sysupgrade,
root@OpenWrt:/# sysupgrade /tmp/openwrt-mvebu-cortexa53-globalscale_espressobin-
emmc-ext4-sdcard.img.gz
Mon Aug 29 01:26:37 UTC 2022 upgrade: Device globalscale,espressobin not supported by this image
Mon Aug 29 01:26:37 UTC 2022 upgrade: Supported devices: globalscale,espressobin-emmc
Mon Aug 29 01:26:37 UTC 2022 upgrade: Reading partition table from bootdisk...
Mon Aug 29 01:26:37 UTC 2022 upgrade: Extract boot sector from the image
Mon Aug 29 01:26:37 UTC 2022 upgrade: Reading partition table from image...
Mon Aug 29 01:26:37 UTC 2022 upgrade: Partition layout has changed. Full image will be written.
Image check failed.
Force it, give it a try?
Thanks!
if you have a backup - sure - give it a try
Did You read that output carefully? It states that on SD card You have firmware for globalscale,espressobin but trying to sysupgrade with image for globalscale,espressobin-emmc.
Yep, agreed! Caught that myself as well . I admit, not sure about MicroSD vs. eMMC (what the HW delta is, and what is supported), but moved to non-emmc. Closer, and I can force sysupgrade, but now I see,
Unable to determine upgrade device
Not sure (yet) how to specify / force that device (/dev/mmcblk0).
Thanks!
The eMMC is soldered to board "SD card", something that is fixed. If You don't have it, no point to use that image, since it only enables that device and might change the index number of /dev/mmcblk. This could be the cause why You're seeing Unable to determine upgrade device.
The instruction for initial putting the firmware on SD card are always the same. What follows is changing bootcmd in U-Boot depending on the version. You should follow it from here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=584d7c53bd2d286a71fe5e8244624f59c529cb26.
That does help, thanks! FYI, I had the MicroSD set up, and sysupgrade re-partitioned it on me ... then I found init issues => wasn't aware of the U-Boot change needed then, will give that a try.
So I need to manually re-build and boot from MicroSD ... vs. initramfs boot, flash the MicroSD with sysupgrade?
Thanks!
Installation is simple, on PC:
zcat openwrt-mvebu-cortexa53-globalscale_espressobin-squashfs-sdcard.img.gz | sudo dd of=/dev/mmcblkN
where N is the index number of a card slot.
In U-Boot command line run:
setenv bootcmd "load mmc 0:1 0x4d00000 boot.scr; source 0x4d00000"
saveenv
That's it. Unless You got different U-Boot version.
That does help, thanks! I was using ext4 ... but you recommend squashfs. Any particular reason why? Just curious 
. And do you know, is there a way to get a directory listing in U-Boot? No biggie, also just curious. I have been hunting around, no luck finding it.
But all that curiousity aside . The one consistent issue I am seeing - random reboots. For example, I loaded the (non-emmc) files as you note, and it does boot ... but after a period of time (~ 15 min or so this time) ... random reboot. I see the same with initramfs, so it's not a file system issue. I am running,
U-Boot 2022.04-OpenWrt-r19590-042d558536 (Jul 31 2022 - 15:12:47 +0000)
And,
OpenWrt 22.03.0-rc6, r19590-042d558536
Any thoughts would be greatly appreciated! The pain is ... on reboot, of course the kernel log is lost 
. So difficult to debug.
OK, one more curiousity ... LOL!. Why the address 0x4d00000? I admit, I don't know what the memory map is for this board (v5).
Thanks!!
ext4 vs squashfs is just an example. The squashfs is read-only plus overlay so You can't change it, means it'll reboot to factory settings if overlay is broken. ext4 if fully rw, so if it breaks on power cut, You are on Your own.
You need to hook serial console and see what happens. If these are "random" reboots, that's indicator that Your board will fail at some point (unless it doesn't happen with older OpenWrt versions, then it might be an software issue). Try to apply some cooling to the SoC, if it's new, RMA it. I had one on me failing. Globalscale is probably aware of the issue and what's causing it (search for "netgate sg-1100 keeps rebooting") but for whatever reason keeps mouth shut. Avoid them like plague.
0x4d00000 is a script address which in older U-Boot wasn't defined. You can replace it with ${scriptaddr} or ${loadaddr} if You have them defined in environment.
Sorry for the delay, have been doing some digging here. Not sure the reboot issue is temperature related - sensors seems to be reporting sub-40C. But ... if I try to actively do "things" (like opkg update), it goes south more quickly ... or seems to. Perhaps memory related? I need to do some more digging - perhaps memory testing, speed changes, etc. Will let you know what I find! 
Thanks!
There were some random reboots mentioned in early 21.02 threads for this board too. I think they were resolved with U-Boot updates though.
I am still running 19.07 but plan to upgrade to 21.02 tomorrow. I already upgraded my U-Boot last year.
Was wondering about that, but I have updated, running,
U-Boot 2022.04-OpenWrt-r19590-042d558536 (Jul 31 2022 - 15:12:47 +0000)
aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r19426-2b1941e47d) 11.2.0
GNU ld (GNU Binutils) 2.37
Could it be CPU or memory speed related?
Thanks!
FYI, just booted via initramfs (v21.02.3), didn't stay up 2 min => rebooted. Not thinking that's temperature, but I could be wrong!
I found the old posts - the issue was actually related to the CPU frequency governor. Maybe the problem is the kernel in the release candidate - have you tried the 21.03 release instead?
Yes, typo above on my part, but that's the release that randomly rebooted most recently. Is there a change I can make (for the governor), try a new build? I can build myself, no issue there.
Thanks!