Ok, it looks like it is stuck unless i remove the usb-to-ttl adapter, but once I remove it and plug it back in, then it moves forward.
But it seems to halt in U-Boot, and not load the Openwrt root partition. Any idea what could cause this?
@ghoffman
I flashed 23.05.5 to both partitions a few days ago and had 22.x.x on it for a few month about a year or two ago. I try to use it in a different project. It used to be a little bit flakey in the past, but generally worked. It was attached via powerlan so I thought that was the reason.
@anomeome ah I see, I figured I could use the serial method as well.
and both run nandboot and run altnandbootwill boot into OpenWRT, but I am not sure it did really load different images:
First try:
BusyBox v1.36.1 (2024-09-23 12:34:46 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 23.05.5, r24106-10cc5fcd00
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:/# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 4.5M 4.5M 0 100% /rom
tmpfs 248.0M 60.0K 248.0M 0% /tmp
/dev/ubi0_1 55.4M 212.0K 52.4M 0% /overlay
overlayfs:/overlay 55.4M 212.0K 52.4M 0% /
ubi1:syscfg 70.2M 488.0K 66.1M 1% /tmp/syscfg
tmpfs 512.0K 0 512.0K 0% /dev
Second try:
BusyBox v1.36.1 (2024-09-23 12:34:46 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 23.05.5, r24106-10cc5fcd00
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:/# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 4.5M 4.5M 0 100% /rom
tmpfs 248.0M 60.0K 248.0M 0% /tmp
/dev/ubi0_1 55.4M 204.0K 52.4M 0% /overlay
overlayfs:/overlay 55.4M 204.0K 52.4M 0% /
ubi1:syscfg 70.2M 488.0K 66.1M 1% /tmp/syscfg
tmpfs 512.0K 0 512.0K 0% /dev
Should the /overlay devices be the same? Probably not, right?
I always seem to end up in Partition 1.
Tried /usr/sbin/fw_setenv boot_part 2 && reboot as well, but it didn't help, so maybe U-Boot and the two partitions are broken?
What would be the best way to reset U-Boot as well?
#!/bin/sh
#hacked from /lib/upgrade/linksys.sh
cur_boot_part=`/usr/sbin/fw_printenv -n boot_part`
target_firmware=""
if [ "$cur_boot_part" = "1" ]
then
target_firmware="kernel2"
fw_setenv boot_part 2
fw_setenv bootcmd "run altnandboot"
elif [ "$cur_boot_part" = "2" ]
then
target_firmware="kernel1"
fw_setenv boot_part 1
fw_setenv bootcmd "run nandboot"
fi
# re-enable recovery so we get back if the new firmware is broken
fw_setenv auto_recovery yes
echo "$target_firmware"
reboot
I have been running run nandboot and run altnandboot fro U-Boot by hand, I think wrapping a script around it probably wont make a difference.
Marvell>> run altnandboot
NAND read: device 0 offset 0x5a00000, size 0x600000
6291456 bytes read: OK
## Booting kernel from Legacy Image at 02000000 ...
Image Name: ARM OpenWrt Linux-5.15.167
Created: 2024-09-23 12:34:46 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3456053 Bytes = 3.3 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
and
Marvell>> run nandboot
NAND read: device 0 offset 0xa00000, size 0x600000
6291456 bytes read: OK
## Booting kernel from Legacy Image at 02000000 ...
Image Name: ARM OpenWrt Linux-5.15.167
Created: 2024-09-23 12:34:46 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3456053 Bytes = 3.3 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
What I am seeing is that they read from different offsets ( 0x5a00000 vs 0xa00000 ) and after another try I seem to get into the second partition:
BusyBox v1.36.1 (2024-09-23 12:34:46 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 23.05.5, r24106-10cc5fcd00
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:/# /usr/sbin/fw_printenv -n boot_part
2
I assume this means that this is a U-Boot issue and not an image issue, because unless I do run nandboot nothing happens, right?
As far as I see you are successfully booting each partition. Can you not save changes to one / both, one / both do not reboot on their own. Any error in bootlog on initial boot: dmesg | grep -i err
I think I don't fully understand, what you mean.
My problem is: no partition at all boots on its own. U-Boot seems to stall. I think dmesg would show only messages after the kernel was selected and already started, right?
From your OP you said cannot save, will not reboot. I see kernel2 boot in the above post. If just partition 1 is borked, maybe try flashing an image, whether by tftp with uboot run flash_pri_image, or from partition 2 image.
I tried a reset of the environment variables of U-Boot, but this didn't work either. It looks like my WRT3200ACM is stuck in U-boot without the boot command being run.
mtd erase kernel1
mtd write openwrt...factory.img kernel1
mtd erase kernel2
mtd write openwrt...factory.img kernel2
reboot
`
this gets both partitions initially flashed.
i still generally have to sysupgrade twice, which efectively gets me back to the original partition. any changes to the defaults arent saved with the first sysupgrade, so you end up on the 2nd partition with default values. sysupgrading again gets yo back to partition 1, where your changed variables are still rpesent.
as I and others have documented, this has been a problem for the mvebu wrt sereis for about 4 months now.
the issue is documented throughout the forum and here:
but it is still not being picked up for investigation