I got the replacement and it's not a 640N but a 640W (or whatever the WiFi/non-LTE model is). It works much better than the first one but I assume I can't really use it as a firmware donor for the 640N?
Dell VEP/VMWare Edge/Velo Cloud SD-WAN/VeraCloud VEP1400/VEP1400-X firewall units
- Thread starter j_h_o
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
You can, using the standard recovery/restore features. No special sauce needed. Start with the BIOS/UEFI; do a 'save' from the flash tool, then copy it to your previous device and 'restore'.
If that works, the next step is the CPLD, if you can't dump it, you can use the ISP header to extract it and load it into the previous unit.
If that works, the next step is to compare the TLV data from eda and see if there is anything missing (probably not, your dump looks good), and next is the PIC if that is installed on the 6x0 series.
What firmware did the second unit update to? Does it end in -21 or -23? There's some subtle difference. However, there is no separate VEP1400-X-BIOS-3.50.0.9-21.bin available. Is it embedded in the vep1400x_ufw_2.6 script?
The Wi-Fi module is PCIe. It should have no interaction with CPLD or PIC. I think everything is the same except for this possible 21/23 discrepancy.
Last edited:
It updated from 3.50.0.9-10 to 3.50.0.9-21. This is the TLV info from it:
Code:
TLV Name Code Len Value
-------------------- ---- --- -----
Product Name 0x21 7 EDGE640
Part Number 0x22 6 06JKR2
Serial Number 0x23 20 TW06JKR2DNG0015O0638
Base MAC Address 0x24 6 18:5A:58:C7:66:60
Manufacture Date 0x25 19 05/25/2021 08:24:53
Device Version 0x26 1 1
Label Revision 0x27 3 A00
Platform Name 0x28 22 x86_64-dellemc_edge640
MAC Addresses 0x2A 2 64
Manufacturer 0x2B 5 DNG00
Country Code 0x2C 2 TW
Vendor Name 0x2D 8 Dell EMC
Service Tag 0x2F 7 B0CCV43
Vendor Extension 0xFD 21 0x00 0x00 0x02 0xA2 0x20 0x09 0x1A 0xF4 0xFE 0x2A 0x40 0x49 0x0E 0xB9 0x0D 0x99 0xF1 0x1C 0x50 0xDF 0x84
Diag Version 0x2E 12 3.43.3.81-27
CRC-32 0xFE 4 0x810DDD68
Checksum is valid.
[VEP1400-X] Board ID : 0x0aThe update package is some kind of hybrid archive with a script at the beginning. If you look at the startup, you'll see:
Code:
Uncompressing release 100%
firmware_updater/
firmware_updater/lib_setup.sh
firmware_updater/install.sh
firmware_updater/lib_unsetup.sh
firmware_updater/firmware.files
firmware_updater/os/
firmware_updater/os/centos/
firmware_updater/os/centos/centos_init.sh
firmware_updater/os/velo/
firmware_updater/os/velo/driver/
firmware_updater/os/velo/driver/v4.14.106/
firmware_updater/os/velo/driver/v4.14.106/amifldrv_mod.md5sum
firmware_updater/os/velo/driver/v4.14.106/amifldrv_mod.o
firmware_updater/os/velo/driver/v4.14.239/
firmware_updater/os/velo/driver/v4.14.239/amifldrv_mod.md5sum
firmware_updater/os/velo/driver/v4.14.239/amifldrv_mod.o
firmware_updater/os/velo/driver/v4.14.149/
firmware_updater/os/velo/driver/v4.14.149/amifldrv_mod.md5sum
firmware_updater/os/velo/driver/v4.14.149/amifldrv_mod.o
firmware_updater/os/velo/velo_init.sh
firmware_updater/os/ubuntu/
firmware_updater/os/ubuntu/ubuntu_init.sh
firmware_updater/os/versa/
firmware_updater/os/versa/versa_uninit.sh
firmware_updater/os/versa/driver/
firmware_updater/os/versa/driver/i2c-ismt.ko
firmware_updater/os/versa/versa_init.sh
firmware_updater/os/common_func.sh
firmware_updater/os/debian/
firmware_updater/os/debian/driver/
firmware_updater/os/debian/driver/9.9/
firmware_updater/os/debian/driver/9.9/amifldrv_mod.o
firmware_updater/os/debian/driver/10.2/
firmware_updater/os/debian/driver/10.2/amifldrv_mod.o
firmware_updater/os/debian/driver/10.0/
firmware_updater/os/debian/driver/10.0/amifldrv_mod.o
firmware_updater/os/debian/driver/9.8/
firmware_updater/os/debian/driver/9.8/amifldrv_mod.o
firmware_updater/os/debian/debian_init.sh
firmware_updater/firmwares/
firmware_updater/firmwares/Linux_DLMC_SFDN007E_20240704_New.tar
firmware_updater/firmwares/SBR10015_646_1TB_m2_2280_D_DEL_ISP.bin
firmware_updater/firmwares/vep1400x_cpld_versa_transfr_v18_2023_0424.vme
firmware_updater/firmwares/VEP1400-X-BIOS-3.50.0.9-21.bin
firmware_updater/firmwares/N1406_App_V40Q_230414.bin
firmware_updater/firmwares/N1406_App_V20P_220223.bin
firmware_updater/firmwares/vep1400x_cpld_gris_transfr_v2a_2023_0410.vme
firmware_updater/firmwares/VEP1400-X-BIOS-3.48.0.9-23.binFor those unaware (including myself), the command to print the device info is:
Code:
eepromtool -P IDEEPROM -x
Last edited:
The CPLD is vep1400x_cpld_versa_transfr_v18_2023_0424.vme (vep1400x_cpld_gris_transfr_v2a_2023_0410.vme). The variations are mostly related to whatever board and build ID the device is, which is why it's important to let the updater read the board data and select the correct XML, and then let the correct XML find the correct CPLD to load. If it loads the wrong one, it will reconfigure the ports in a way that makes it not accessible from the C3000.
They didn't lock the CPLD and you can actually read and write it using the official tools (there's even a Docker container for it so you don't end up spraying gigabytes or random crap all over your OS). The VMEs are essentially bitstreams and you can load them as long as they match the CPLD family.
The way they integrate it seems to be mostly about managing the switch chips and NIC sideband channels, as well as the LEDs so they don't have to be controlled from software.
The header on the PCB is almost always populated, they're are 2 DIP-switches as well, don't remember which one but they can be used to disconnect the CPLD from the rest of the board so you can ISP it.
Another edit: the bottom of the ID will show the board ID (but not always the variant): [VEP1400-X] Board ID : 0x0a
What's great about this is that the packages are provided at that level, including most if not all possible variants; so a VEP1400-X package should always be able to flash the entire set of firmwares (UEFI, PIC, CPLD).
The biggest differences will be in the installed/available devices and how the PIC and CPLD are configured as they have slight differences between VersaOS, VeloCloud, VMWare etc. Since we have some dumps of the normal OS runtimes and they (somewhat dirty) just put most of their I2C startup code in rc.local we know what addresses to talk to for which function, same as the XMLs that tend to have the correct pin configuration depending on the installed payload.
The other firmwares in the package are usually not really critical to the main board and are mostly about SSD controller firmwares etc.
They didn't lock the CPLD and you can actually read and write it using the official tools (there's even a Docker container for it so you don't end up spraying gigabytes or random crap all over your OS). The VMEs are essentially bitstreams and you can load them as long as they match the CPLD family.
The way they integrate it seems to be mostly about managing the switch chips and NIC sideband channels, as well as the LEDs so they don't have to be controlled from software.
The header on the PCB is almost always populated, they're are 2 DIP-switches as well, don't remember which one but they can be used to disconnect the CPLD from the rest of the board so you can ISP it.
Another edit: the bottom of the ID will show the board ID (but not always the variant): [VEP1400-X] Board ID : 0x0a
What's great about this is that the packages are provided at that level, including most if not all possible variants; so a VEP1400-X package should always be able to flash the entire set of firmwares (UEFI, PIC, CPLD).
The biggest differences will be in the installed/available devices and how the PIC and CPLD are configured as they have slight differences between VersaOS, VeloCloud, VMWare etc. Since we have some dumps of the normal OS runtimes and they (somewhat dirty) just put most of their I2C startup code in rc.local we know what addresses to talk to for which function, same as the XMLs that tend to have the correct pin configuration depending on the installed payload.
The other firmwares in the package are usually not really critical to the main board and are mostly about SSD controller firmwares etc.
Last edited:
Could someone give me a few pointers what kind of software I need for the CH341A to flash the CPLD (preferably on Linux)? Also I’d like to be certain which header to connect to. I have tried the in-band method of updating the CPLD but it runs up against the same error because it can’t see the CPLD (in the way it wants to at least).
The header is a dedicated ISPDownload header that works with Diamond (Free) and most FT2232H boards. IIRC it's all just JTAG but you can use any MPSSE type engine, doesn't need a segger or lattice device.
If you don't want Diamond spreading all over your OS, you can get a Dockerized version from examples like these: GitHub - Gekkio/docker-fpga: Dockerized FPGA toolchain experiments
Yeah that will probably work fine like any of the other USB JTAG adapters. I think the biggest thing about most of them is using one of the standard FTDI chips so the Lattice software treats it like an official FPGA/CLPD JTAG cable. I used this one: TIAO USB Multi-Protocol Adapter (TUMPA) — PlatformIO latest documentation but I'm not sure where they are sold at this point. They are all just reference designs from FTDI anyway so whatever you can find that is easy for you to use will work.
The header is a standard JTAG pinout so that's easy enough. Also, if you're unsure there's a JTAG detector program where you plug in the FTDI chip and run it to find out the correct pinout (i.e. GitHub - szymonh/JTAGscan: Identify JTAG ports using your favorite Arduino. ).
Last edited:
I've found some time to do experimentation on this. I have the FT2232H connected (and I think recognized in Lattice Diamond). I've tried to connect it to the board in this manner:
* Pin 5 (not the pin with the white dot but the one next to it) = GND
* Pin 3 = BDBUS2 = TDO/DI = FSDO
* Pin 6 = BDBUS1 = TDI/DO = FSCLK
* Pin 7 = BDBUS0 = TCK/SK = FSDI
Let me know if that looks correct or if I have that all wrong.
I'm also having issues with the Lattice Diamond Programmer on Linux (getting a "Failed to Open FTDI USB port", which some people fix with unloading ftdi_sio driver but that doesn't seem to work). I'll try this on a Windows PC as I've seen people have more luck with that. I bet doing this on NixOS is adding unnecessary issues to this as well.
So I thought I'd at least confirm the JTAG pinout. I downloaded the datasheet for LCMXO2-1200HC, but there's no pinout. Apparently, the pinout can be generated from the Lattice software. You can't download the software without an account. I can't reset my password from years ago because they claim I have no account. I can't create an account because they rightly claim my e-mail is already registered. If they can't fix it, then I'll just use a different e-mail. I have an FT2232HL-based ESP-Prog that I purchased back in 2020. Have you verified the voltage? The CPLD can operate at either 2.5V or 3.3V. My JTAG interface only has options for 3.3V or 5V. The FT2232HL natively supports 1.8V and 3.3V (5V tolerant) I/O. The ESp-Prog does include a 74AHC125BQ buffer.
I remember one of the pins needing to be pulled up or down to select the TAP, I have a breadboard with 3 wires and a resistor, probably some voltage divider. I sadly don't have enough time this week to rebuild my test setup, but I did find a project box with a VEP1400, TUMPA and I also still have the docker image in my local cache on a Debian box, so this should be easy enough to setup again (if life stops eating all my time).
That's J1, the wrong header! It has to be the one I circled.
Last edited: