Hi everyone,
I'm trying to recover a Cisco AIR-AP2802I-E-K9 (Mobility Express) that behaves very strangely.
Problem
Every time the AP loses power and boots again, it always stops at the BootROM board selection menu:
Please choose one of the following boards:
1. 3K
2. 2K (new)
3. 2K (proto)
4. Milos
5. 2KH
6. 3KVE (v-sku)
7. 3KH/3KA/4K
8. Duplo
init>>
It never boots automatically.
If I manually continue, it reaches U-Boot and then boots Mobility Express normally.
BootROM
BootROM - 1.78
Booting from SPI flash, Secure mode
RSA Public key verification PASSED
CSK block signature verification PASSED
Boot header signature verification PASSED
Box ID verification PASSED
Detected Device ID 6920
Board: Barbados-2K
U-Boot
U-Boot 2013.01
Board: Barbados-2K
CPU: Marvell Armada 88F6920
RAM: 1GB
SPI Flash: 4MB
NAND: 256MB
Environment:
bootcmd=nandboot
BOOT=part1
activepart=part1
boardid=0x21
FACTORY_RESET=0
MANUAL_BOOT=0
Firmware
The AP boots successfully into Mobility Express.
show boot
Primary Boot Image: 8.10.151.0
Backup Boot Image : 8.10.196.0
Both images appear healthy.
The AP can boot and run normally.
NAND
nand info
shows normal NAND.
The filesystem exists.
nand dump 0x200000 0x100
starts with
55 42 49 23
which is the UBI header.
So NAND does not appear empty or corrupted.
SPI
SPI is readable and writable.
saveenv
works successfully.
U-Boot supports:
sf read
sf write
sf erase
sf update
Strange behavior
dump_board_env reports:
Board ID: Unknown (default to 3K)
Flags=00000000
while U-Boot itself reports:
boardid=0x21
So U-Boot knows the board ID, but dump_board_env does not.
What I've already tried
- Factory reset
- Reboot
- Power cycle
- Booting both firmware images
- Verified Secure Boot passes
- Checked NAND
- Checked UBI
- Checked U-Boot environment
saveenv
clear_board_env
resetenv
None of these changed the behavior.
My question
Since both Mobility Express images are healthy, I don't think this is a normal firmware recovery case that requires TFTP.
Has anyone seen an AIR-AP2802I that always enters BootROM init>> after every power cycle?
Could this indicate corrupted manufacturing/board environment stored in SPI rather than a firmware problem?
Is there a known way to restore the board environment, or force BootROM to skip the board-selection menu?
Any ideas would be greatly appreciated.Hi everyone,