Adding OpenWrt support for Ctera C200 v2

For Developers
1

Edited to provide useful links

Original content

I saw an existing pull request for the Ctera C200 v1, and became interested in the device. It appears the devices are EoL and are slowly being sold off.

I purchased two, but upon disassembly discovered they are not Ctera C200 v1, but rather, v2, or so I interpret: the model number is 'CT-C200-2'; the SKU is 'CTERA-EC200', as seen for example in this photograph:

image
image1024×768 72.4 KB

I disassembled and took some photographs:

image
image1920×1118 308 KB

Then, I connected to the serial cable (starting from the pin pointed to by the silkscreen carat, the serial pinout is: VCC, RX, TX, GND, as with most Marvell boards).

Upon boot, I got these messages:

BootROM 1.08
Booting from NAND flash
High speed PHY - Version: 2.1.2 (COM-PHY-V20)
mvBoardSerdesModulesScan: mvTwsiRead erro serdes to default ****High speed PHY - Ended Successfully
                   DDR3 Training Sequence - Ver 4.4.0
DDR3 Training Sequence - Ended Successfully
Status = MV_OK
BootROM: Image checksum verification PASSED


U-Boot 2011.12-g29cf28a (Nov 17 2014 - 17:13:47) Marvell version: v2011.12 2013_Q1.0p2

Nanya-DDR
ESMT-2GB-NAND
   ** CTera BootCode: 3, CTera Board: 2Drive_A **
Board: DB-88F6710-BP
SoC:   MV6710 A1
CPU:   Marvell PJ4B v7 UP (Rev 1) LE
       CPU    @ 1000 [MHz]
       L2     @ 667 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 667 [MHz]
       DDR 16Bit Width, FastPath Memory Access
DRAM:  1 GiB
2

The one thing that has completely stalled me is getting into the bootloader.

It is possible to get the device to accept TFTP PUTs at its default address (192.168.0.1) by holding the reset button as it boots. So if a firmware can be built in the same way as it's done for the v1, then it can probably be pushed to the device to reset it.

3

Based on the boot log that is an Armada 370 based device instead of the Kirkwood based Ctera C200 V1. That would use the ARM v7 based mvebu target. Which would make your device similar to the Buffalo LS421DE.

4

Hey there,

Yeah, I'm aware how similar it is to the LS421DE. I don't have any way to get control over the machine other than to flash the firmware, so I will probably try to just build based on the firmware formulation provided by @CHKDSK88.

The biggest anxiety I have is actually the device-tree: I don't have any way to back up the firmware on the existing system to produce a decompiled device-tree.

5

@hurricos

Ctera V2 was donated to me, byt my device has broken bootloader. Could You send me stock bootloader dump?

6

Unfortunately not! I can't actually get a dump of the system as I do not have a way to copy off of the NAND.

This is sort of a chicken-and-egg problem: If I had a copy of the dtb, rootfs and kernel, I could (probably very easily) use the ctera-firmware recipe to restore-to-stock via the TFTP boot method available by holding 'reset' and TFTP PUTting a manually built firmware .tar file.

I was almost able to log in via the console shell, but unfortunately since a default admin user does not have a home directory, it won't let you login on the console even if you do have the right password. There is a menu in the web GUI to set the home directory for each user; maybe if I add a USB disk, allocate a home directory for admin and try again, I will be able to log in via the console and then take dumps of the mtd, at which point I could confirm a revert-to-stock-via-TFTP firmware can be built, and at which point I could experiment with building OpenWrt using your ctera-firmware recipe, @CHKDSK88.

7

@hurricos If You will able to make backup, please remember about me. :slight_smile:

My proposal is different: Did You think about hack stock firmware image and unlock access to shell? We know how image is build, so it's should be possible to make some changes in initramfs image.

8

Hey there @CHKDSK88: I absolutely will post if I manage to get a dump.

As for replacing the stock firmware: I have no sources for firmware images, and no device-tree with which to build a replacement OpenWrt initramfs (though I could make some educated guesses).

Addendum: If I can't get a root shell with the existing firmware, I can instead, as per @danitool, build barebox for the board and use his copy of some Buffalo Linkstation u-boots to source the RAM training program. Regarding building barebox, he suggests building the OpenWrt mvebu toolchain and then using the following exports to build barebox:

# hurricos: these were my exports for barebox (found in my notes)                      
export CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf-                                   
export KBUILD_OUTPUT=../build                                                        
export ARCH=arm                                                                      
make mvebu_defconfig                                                                 
export STAGING_DIR=/run/media/dani/DT01ACA3/OPENWRT/snapshot-linkstation/staging_dir 
make                                                                                 
# well this has no much sense to me right now                                          
# btw compiling barebox it's easy once you give it the path of the right toolchain

One more thing to add: @hmartin provided a Dockerfile to build Marvell Armada u-boot: this might not support Armada 370 (I believe this u-boot release is after u-boot-marvell purged stuff for the Armada 370), but it'd be worth a shot if we want to rebuild U-boot from scratch and set up a new board definition for build.pl -- or if CTERA ever releases u-boot sources.

9

Please test very WIP branch:

Factory image works, ethernet works, sysupgrade works, back to stock should work because it's copied from kirkwood.

I hope, it's enough to make copy of mtd0. :slight_smile:

1 Like
10

Built and tested. It works. I have sent you a copy of my bootloader.

Thank you!

1 Like
11

Thank You for image. It works from uart, but it fail from nand. I don't know where is the problem. Image is proper, no badblocks, but checksum is still broken.

EDIT:
@danitool
Could You give me some advice?

12

Not sure if I've understood correctly. Are you trying to restore an image of the bootloader?

13

Hey @danitool. He is, yes: see this forum thread.

I can think of two reasons why the checksum might still be wrong:

  • NAND drivers aren't acting appropriately for writing
  • the checksum is of more (or less) than just the U-boot area.

To squash the second option @chkdsk88, I'll get you a full NAND dump of my router soon, so you can boot OpenWrt and write the entire NAND.

14

Yes. My device fall into bootloop, when is booting from NAND.

I tried "bubt" flashing from marvell bootloader
u-boot nand write
linux nand write
dd

I used three different u-boot images and still is invalid checksum after boot. Nand has no badblocks in bootloader area, if I use compare, nand and image are equal.

I have no idea how to fix it.

15

@hurricos

Could You paste result of command: CTera>> md d001822c from u-boot? It could be from esmt_1mb.bin.bin booted from kwboot.

16

Hey @CHKDSK88: here's a .tar made up of .gz's of the /dev/mtd*s of my C200 V2:

https://downloads.laboratoryb.org/c200v2/full_dump/c200_v2_openwrt_flashed_mtds.tar

17

Thanks for the dump.
Could You paste result of command: CTera>> md d001822c from u-boot?

I almost done support for it. My branch was force pushed. What left?
fan control
hdd temp handle
usb1/2 led trigger
check which pins are buzzer pins

18 
CTera>>md d001822c 
d001822c: 00000000 001a2795 00000000 00000000    .....'..........
d001823c: 00067101 00000000 00000000 00000000    .q..............
d001824c: 0000000e 00000000 00000000 00000000    ................
d001825c: 00000000 00000066 00000000 00000000    ....f...........
d001826c: 00000000 00001111 00000000 00000000    ................
d001827c: 00000000 00000000 00000000 00000000    ................
d001828c: 00000001 00000000 00000000 00000000    ................
d001829c: 00000000 00000000 00000000 00000000    ................
d00182ac: 00000000 00000000 00000000 00000007    ................
d00182bc: 00000000 00000000 03f00000 00000000    ................
d00182cc: 00000000 6f001000 ffff0000 00000000    .......o........
d00182dc: 00000000 ffff0000 ffff0000 ffff0000    ................
d00182ec: ffff0000 00000000 ffff0000 ffff0000    ................
d00182fc: ffff0000 09148712 26489850 00000000    ........P.H&....
d001830c: 00000241 00000700 00000700 00000000    A...............
d001831c: 00000000 00000000 00000000 00000000    ................

In addition, I have left my C200 V2 in U-boot on the work bench. I will be back to it in 15 hours from now, give or take. Please let me know if you have any other requests for memory displays from me.

19

@hurricos

Thank for the memory dump. Your device have 001a2795 in Sample at Reset register. My device 001a27b5. Good device have bits[6:1]: 0xA = Boot from 8-bit NAND flash, 4-bit ECC, 2KB page size. My device is configured different: 0x1A = Boot from 8-bit NAND flash, 12-bit ECC, 2KB page size.

It means that my bootloader is perfectly fine. I have problem with hardware. Some of strap resistor is isn't soldered properly.

Thanks for the help with debugging. I let You know when final PR will be ready.

20

It was the most stupid problem with hardware ever: UART adapter hold Boot source[4] in wrong state...