Vocore v1 Upgrade to Latest OpenWRT

[ad7zj]

I tried to upgrade to the latest OpenWRT (22.03)using the image here:
https://openwrt.org/toh/vocore/vocore?d ... tall%20url
I had LEDE 17.01 on it previously and used sysupgrade to load the latest OpenWRT image.

However it cannot boot now, the bootloader gives the following output:

Code: Select all

U-Boot for VoCore(based on RT5350)Warning: un-recognized chip ID, please update bootloader!
.
Version: May 30 2014 20:52:36

Press 'x' to console...


Booting image at bc050000 .
   Image Name:   MIPS OpenWrt Linux-5.10.146
   Created:      2022-10-14  22:44:41 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    1629312 Bytes =  1.6 MB
   Load Address: 80000000
   Entry Point:  80000000
   Load Kernel:  .........................

   Verifying Checksum ... OK
   Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover


Has anyone else tried this? Is this an issue with the old version of u-boot? Would be cool to keep these old guys still running

[Vonger]

Hi,
Such problem seems like the firmware is not correct, so it can not pass LZMA check but not hardware itself has problem.

[ad7zj]

Yeah, I don't think there is anything wrong with the hardware. I have successfully reloaded the default firmware from here: https://vocore.io/v1d.html

However when I try to load more recent firmware, uboot doesn't seem to accept it. Is uboot limited to 4MB? I built the latest openwrt myself and got it just under 4MB by making the wifi and usb kernel modules loadable instead of built in. However, that also didn't work. I can download it to uboot using loadb, then the kermit transfer, then I give uboot the erase linux command. So far so good. However, then I run cp.linux [size in bytes] and it just returns immediately. No errors, but it doesn't spend any time writing and after a reset, the magic number is 0xFFFFFFFF - and of course it can't find the image, can't boot.

[ad7zj]

I tried another approach - reload the original vocore firmware, then flash the firmware I built from latest openwrt source using sysupgrade. But, still same result. Neither my firmware nor the official openwrt builds work, both give the same error at boot.

It seems LZMA error 1 is a very generic error, no idea what is wrong. Do you know any other ways to get more clues?

[ad7zj]

I thought maybe something was wrong with the LZMA arguments but after comparing them to an older LEDE image which works, it's not that - they're the same. So maybe it really does have to do with not enough space. See this binwalk of the latest OpenWRT released build:

Code: Select all

elijah@elijah-Latitude-E6520:~/projects/vocorev1/openwrt$ binwalk ~/Downloads/openwrt-22.03.2-ramips-rt305x-vocore_vocore-16m-squashfs-sysupgrade.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0xD690C403, created: 2022-10-14 22:44:41, image size: 1629312 bytes, Data Address: 0x80000000, Entry Point: 0x80000000, data CRC: 0x8EB6FF66, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-5.10.146"
64            0x40            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 5439347 bytes
977256        0xEE968         MySQL ISAM index file Version 4
1629376       0x18DCC0        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 3481446 bytes, 1349 inodes, blocksize: 1048576 bytes, created: 2022-10-14 22:44:41


Uncompressed size is > 5MB

The original uboot source has been lost, so I started looking through noblepepper's uboot - it should be similar. The boot process happens in this file: https://github.com/noblepepper/ralink_s ... md_bootm.c Notice that it copies the compressed kernel image from SPI flash into memory at CFG_SPINAND_LOAD_ADDR 0x80500000. The image is uncompressed at 0x80000000, leaving 5 MB of space max for the uncompressed image before it starts overwriting the compressed image.

That's my best guess for now - so maybe it would be possible to rebuild uboot and redefine CFG_SPINAND_LOAD_ADDR a few MB up higher?