My system has worked without problems for a few months until today I had to see that the Gx device no longer boots and is stuck in the init process. On the serial console you can see that a file for the init process is missing. My guess is that the file system was corrupted for some reason.
You will have to strip your machine to get the SD card of the GX and flash it with the nanopi image for Victrons OS. This may or may not work.
This is potentially, if not done carefully, can damage things so if you aren't used to or comfortable doing so take it in for a warranty repair.
Make sure nothing else is on the sd/usb card. It will not work if there is other content.
Unfortunately, my nanopi does not have an SD card. But since I can access the bootloader menu via the serial interface, I will try my luck with this.
The following commands are possible:
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
bootvx - Boot vxWorks from an ELF image
bootz - boot Linux zImage image from memory
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
dhcp - boot image via network using DHCP/TFTP protocol
dm - Driver model low level access
echo - echo args to console
editenv - edit environment variable
env - environment handling commands
exit - exit script
false - do nothing, unsuccessfully
fdt - flattened device tree utility commands
fstype - Look up a filesystem type
go - start application at address 'addr'
gpio - query and control gpio pins
gpt - GUID Partition Table
help - print command description/usage
i2c - I2C sub-system
iminfo - print header information for application image
imxtract- extract a part of a multi-image
itest - return true/false on integer compare
load - load binary file from a filesystem
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loadx - load binary file over serial line (xmodem mode)
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
ls - list files in a directory (default /)
md - memory display
mm - memory modify (auto-incrementing address)
mmc - MMC sub system
mmcinfo - display MMC info
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
printenv- print environment variables
reset - Perform RESET of the CPU
run - run commands in an environment variable
save - save file to a filesystem
saveenv - save environment variables to persistent storage
setenv - set environment variables
setexpr - set environment variable as the result of eval expression
showvar - print local hushshell variables
size - determine a file's size
sleep - delay execution for some time
source - run script from memory
test - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
true - do nothing, successfully
usb - USB sub-system
usbboot - boot from USB device
version - print monitor, compiler and linker version
I intended to boot via USB and then do a "normal" software update. In the hope that the file system on the E-MMC will be restored.
Can you tell me where I can get an image for a Nanopi that I can write to a USB stick?
It is in a link in my above reply.
https://updates.victronenergy.com/feeds/venus/release/images/
There are other options for interface.
After trying to boot from my USB stick with the USBBOOT command, I have now copied an image to a MicroSD card and tried to boot with it. @mvader It is really an understatement to describe the SD card slot as "not visible". It took my inspection camera, a pair of tweezers and a very steady hand to even get an SD card in there.
The biggest problem for me is that there is no description of this procedure. With the USBBOOT command, I already failed at the correct spelling for the USB device. I have read the U-Boot documentation from back to front, but have not found an example.
Same with the mmc subsystem: There is no command to boot from the MMC card, you can only boot from the memory, which you have to load with LOAD first (I assume). But if I don't have a memory map of the nanopi, I don't mean a physical one, I already found that. I mean a logical one, which shows free areas that can be used to load such an image, for example.
I still refuse to go to the trouble of dismantling the Multi, including the cables etc., just because of a file system error! If someone can give me complete instructions on how to fix this error, I am perfectly capable of doing it myself. And without sending it in for repair!
Probably because the average user would take it in for a warranty repair. Most installers i know would do the same.
Not everyone knows or cares to know how to code.
Because Victron relies on so well programmed and tested software (Open Sorce), I chose Victron among others. I have been programming with the RaspberryPi for a long time and have also built hardware extensions for it to read out single wire sensors of my heater. But unfortunately, I have not yet gone into all the depths.
From one point of view it is a very good decision to open source your software. Just so that it can be reviewed and tested by many developers.
@Kevin Windrem, in the meantime I have already found out how to change the boot device in the submarine. Unfortunately it did not change the behavior. I am sure that there is a working "preversion" on the GX device. This can normally be selected via the remote console when the GX would start.
@Kevin Windrem,the submarine thing seems to be a translation feature of Deepl, meaning U-Boot of course,
It would also help me if I could boot from my stick with USBBOOT. Unfortunately I haven't found a correct notation for the USB device yet.
You can change the active boot partition from the boot menu as follows:
editenv version
change 1 to 2 or 2 to 1
saveenv boot
Thanks a lot! Now my GX is running again. It was worth to use Victron, because there is no better quality and more robust software than OpenSource.
