OS 6865 USB Recovery not working

[bjeldred]

Hello. I am trying to recover an Omniswitch 6865. From a working switch, I pulled the files onto my USB and have the certified and working folders. I also copied over the Urescue.img file into the root of my USB, as the uboot prompts instructed me to do so. So my folder structure is :

->6865
---->certified-> .....
----> working -> ......

->Urescue.img

When I run the rescue command on the switch, I get the following output:
u-boot> run rescue
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... USB dev 1, u-boot EHCI Host Controller
device is a hub, probing
USB dev 2,
device is a hub, probing
USB dev 3, SMART EUSB
USB dev 4, SanDisk Cruzer Glide
4 USB Device(s) found
scanning usb for storage devices... 2 Storage Device(s) found
Device 0: Vendor: SMART Rev: 1083 Prod: EUSB
Type: Hard Disk
Capacity: 1909.0 MB = 1.8 GB (3909632 x 512)
Device 1: Vendor: SanDisk Rev: 1.26 Prod: Cruzer Glide
Type: Hard Disk
Capacity: 7633.5 MB = 7.4 GB (15633408 x 512)
** Unrecognized filesystem type **
Wrong Image Format for bootm command
ERROR: can't get kernel image!
u-boot>


Now I have seen some people say that using a larger size USB could be problematic. Is this likely the cause of my failure, or did I do something wrong? Happy to provide more information if needed!

I think the problem may be that it keeps trying to boot on the Smart eUSB, but I need it to boot from my SanDisk usb. Any idea how to fix this? I'm not familiar with the system unfortunately and don't even know what the eUSB is for.

Thanks!

[silvio]

you need the folder /6860/certified.
Within this folder the actual AOS-Image.
Does your stick works at a normal working switch after usb enable ?
BR Silvio

[bjeldred]

I have a /6865/certified folder. Should I rename it to 6860 even though I'm on a 6865 switch?
In that certified folder there's the Urescue.img file, boot.md5, and various .cfg files (vcssetup,cloudagent,vcboot), as well as a software.Ism file. There's also a pkg subfolder. This was all generated from our working switch.

The USB stick has been working yes. From reading through the uboot feed, it seems like the failing network switch keeps trying to do the "run rescue" command from the eUSB, even though it recognizes my SanDisk USB. The system is stuck in a loop which I've pasted below.




U-Boot 2013.01 8.7.R01.74 |armv7_helix4| (Apr 08 2020 - 15:41:39)

BENCH SCREENING TEST1
=========================================
IPROC_XGPLL_CTRL_3: 0x15400000
IPROC_XGPLL_STATUS: 0x800001d8
DCO code: 29
PASS
=========================================
fpga: 0x7f @ 100Khz
DEV ID = 0xdc14
SKU ID = 0x0
DDR type: DDR3
MEMC 0 DDR speed = 750MHz
ddr_init2: Calling soc_ddr40_set_shmoo_dram_config
ddr_init2: Calling soc_ddr40_phy_calibrate
C01. Check Power Up Reset_Bar
C02. Config and Release PLL from reset
C03. Poll PLL Lock
C04. Calibrate ZQ (ddr40_phy_calib_zq)
C05. DDR PHY VTT On (Virtual VTT setup) DISABLE all Virtual VTT
C06. DDR40_PHY_DDR3_MISC
C07. VDL Calibration
C07.1
C07.2
C07.4
C07.4.1
C07.4.4
VDL calibration result: 0x30000003 (cal_steps = 0)
C07.4.5
C07.4.6
C07.5
C08. DDR40_PHY_DDR3_MISC : Start DDR40_PHY_RDLY_ODT....
C09. Start ddr40_phy_autoidle_on (MEM_SYS_PARAM_PHY_AUTO_IDLE) ....
C10. Wait for Phy Ready
Programming controller register
ddr_init2: Calling soc_ddr40_shmoo_ctl
Validate Shmoo parameters stored in flash ..... OK
Press Ctrl-C to run Shmoo ..... skipped
Restoring Shmoo parameters from flash ..... done
Running simple memory test ..... OK
Enabling DDR ECC reporting
clear_ddr: OK
Enabling DDR ECC correction
DDR Tune Completed
WARNING: Caches not enabled
U-Boot at: dfead000
FPGA: 0x7f @ 100khz
Family c
Board ID d
CPLD REV: 0C
OS6865-U28X out of reset

Resetting USB hub
Enabling watchdog reset
SF: Detected MX25L6405D with page size 4 KiB, total 8 MiB
PCIe port in RC mode

==>PCIE: LINKSTA reg 0xbe val 0x1001

**************
port 0 is not active!!
**************
In: serial
Out: serial
Err: serial
arm_clk=1000MHz, axi_clk=499MHz, apb_clk=124MHz, arm_periph_clk=500MHz
Net: Registering eth
Broadcom BCM IPROC Ethernet driver 0.1
Using GMAC0 (0x18022000)
et0: ethHw_chipAttach: Chip ID: 0xdc14; phyaddr: 0x1
serdes_reset_core pbyaddr(0x1) id2(0xf)

USB0: USB EHCI 1.00
scanning bus 0 for devices... USB dev 1, u-boot EHCI Host Controller
device is a hub, probing
USB dev 2,
device is a hub, probing
USB dev 3, SMART EUSB
USB dev 4, SanDisk Cruzer Glide
4 USB Device(s) found
scanning usb for storage devices... 2 Storage Device(s) found
Loading from eUSB device
NVRAM:
IP 0.0.0.0/0.0.0.0 gw 0.0.0.0
Booting from certified/Uos.img
boot device filesystem is EXT2
Hit any key to stop autoboot: 0
265752360 bytes read in 9481 ms (26.7 MiB/s)
## Booting kernel from FIT Image at 70000000 ...
Using 'config@1' configuration
Trying 'kernel@1' kernel subimage
Description: Shasta armv7 kernel
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x700000d0
Data Size: 4318571 Bytes = 4.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x61008000
Entry Point: 0x61008000
Hash algo: crc32
Hash value: 28890720
Verifying Hash Integrity ... OK
## Loading init Ramdisk from FIT Image at 70000000 ...
Using 'config@1' configuration
Trying 'ramdisk@1' ramdisk subimage
Description: Shasta ramdisk
Type: RAMDisk Image
Compression: gzip compressed
Data Start: 0x7041e718
Data Size: 261432287 Bytes = 249.3 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00000000
Entry Point: 0x00000000
Hash algo: crc32
Hash value: ecfbfee5
Verifying Hash Integrity ... OK
Uncompressing Kernel Image ... OK

Starting kernel ...

Starting 6865 Boot Process
Preparing Flash...

mkdir: can't create directory '/vroot': File exists
Copyright (c) 1994-2014 Alcatel-Lucent. All Rights Reserved.
Copyright (c) ALE USA Inc., 2014-2020. All Rights Reserved.

AOS image integrity check failed. Checksum file not found. Rebooting the switch...
Rebooting...
The system is going down NOW!
Sent SIGTERM to all processes
haveged haveged: Stopping due to signal 15

Sent SIGKILL to all processes
Requesting system reboot
[ 47.240000] Restarting system.
[ 47.280000] CPU1: stopping


U-Boot 2013.01 8.7.R01.74 |armv7_helix4| (Apr 08 2020 - 15:41:39)

BENCH SCREENING TEST1

[bjeldred]

Does anyone have a solution to this? I'm still stuck and can't figure out how to proceed. Anything related to MiniBoot I can't actually do because the 6865's have a linux shell and not vxworks. I've tried formatting the usb as ext3, FAT, exFAT, FAT32, and more. Nothing seems to work.

[silvio]

you need the folder with 6860. And you need a stick that is working .... not a big one (max. 8G).
Test your stick at a normal working switch. "usb enable" "show usb statistics" "ls /uflash"
BR Silvio

[bjeldred]

Hi again,

Ok, I've tried it with both a 6860 and 6865 folder. The USB drive does work with "USB enable" on my working switches. It's just the USB rescue that doesn't seem to work. I was using an 8GB Sandisk flash drive. I just found a colleague who has a 1GB flash drive, so I may try that today. Otherwise, I'm not sure what else could be the issue

Thanks!

[silvio]

all is okay. You need urescue.img (for 6865) at the root of the stick and folder 6860/certified with Uos.img.

Not sure about the 6865... but check the following outputs at the u-boot-Prompt:
usb info
usb tree

Mass Storage can be the internal flash ... but also the external stick. You will find it out with the name of the storage.

Depending from the hardware also the following should work to check the attached usb:
fatls usb 1
fatls usb 1 /6860/certified

[bjeldred]

Hi again, thanks for the response.

So I ended up finding a 1GB flash drive and this does work now for running rescue on the 6865. However, once this rescue is complete and the system goes to restart, the following error comes up:

AOS image integrity check failed. Checksum file not found. Rebooting the switch..


This is due to the switch being in Enhanced mode. Now I was able to find a Uos.img SHA256 hash value from a working switch I have, but I'm not quite sure what the next steps are to get the AOS image integrity check to succeed on the failed switch. The documentation is a bit lacking on this front, it appears. Should I be saving this hash as a .txt file in the certified folder? Is this hash value even correct if it originates from a different switch?

Any idea what my next steps would be?

The good news is this 1GB USB works

Thanks

[silvio]

if you have now a stick that is working with your switch, than the onliest way is the rescue.
In enhanced mode there is no other way to solve the issue with the integrity check (I have seen the same this week).
Meantime the rescue files are in myportal available.
BR Silvio

[bjeldred]

Thanks! Waiting for a verification email to be sent to me to set up an account. Hopefully that works and thanks for your help.