Dell VEP/VMWare Edge/Velo Cloud SD-WAN/VeraCloud VEP1400/VEP1400-X firewall units

[oneplane]

Yeah, there are a number of serial, ISP, JTAG and SWD headers. The DiagOS also contains a lot of pin mappings and GPIO bit-bang interfaces to access the PIC and CPLD.

As an aside: VMware SD-WAN 5.0 - 软件定义的 WAN - sysin | SYStem INside | 软件与技术分享 seems to have a dump of all the packages, including the VMWare image for the Edge 6x0 (so 600 and 610), but of course they uploaded it to a 'Baidu network disk' with a password on it. The filenames and hashes do match with what VMWare is showing, so that is at least correct, but I don't know where to get the files so far.

Spoiler

VMware SD-WAN Edge Upgrade Package (for Edge 500, 510, 510-LTE, 5X0, and 6X0)
File size: 190.56 MB
File type: zip
Name: edge-imageupdate-EDGE5X0-x86_64-5.1.0.2-5827-R5102-20230310-GA-6ee0ca8b2d.zip
Release Date: 2023-03-14
VMware SD-WAN Edge Upgrade Package (for Edge 500, 510, 510-LTE, 5X0, and 6X0)
This is a software upgrade for the VMware SD-WAN Edge that is deployed on-premise in Datacenter/Bran ch sites. This upgrade package is for Edge models 500, 510, 510-LTE, 5X0, and 6X0.
MD5SUM: 81f3c6b51c7df35440c56e0eae36eb92
SHA1SUM: 94dbb4e1e04880e23cd912925d0a8e74f57be47d
SHA256SUM: d7477639dffa14c2f316c68a824301002918bf2e46fddad94fc9e60f647f0a6d

In theory, they should also have the updates for all the firmware blobs, even Dell support chat refers to them... (which is really weird, since Dell makes those firmwares)

I'm imaging the eMMC for starters so everyone can at least have a working DiagOS, but I don't know how to get the CPLD, it appears the JED files are missing in the DiagOS, but vmetool (which is used to update the code) is present. It can't read from the CPLD, but that might simply be because the program can't do it. Another option is the lock bit is set on the CPLD and thus we cannot read it out.

 

[Brood]

Yeah It looks like we need someone with a active subscription who can download the update and is willing to share it as VMware will not even talk to you if you do not have a subcription.

 

[oneplane]

So, here is some mediocre news about that header near the topside SPI flash and Lattice package;

The header in combination with the two tiny switches is actually an SPI header and the two switches connect the ChipSelect pin to either the top or Botton SPI flash.

1 2 3 4
5 6 7 8

1 = hangs around 1.1v when the device is on
2 = Chip Select -> this is wired up to a diode pack and the two mini-dip-switches which are both off on my board, but switching either on works)
3 = MISO/DO
4 = N/C
5 = GND
6 = CLK
7 = MOSI/DI
8 = VCC (3.3v)

But then there is some 'maybe' news too: there is a single header row on the side near the WLE600 module at the edge of the PCB, and it looks a lot like a Lattice ispDownload header with both JTAG and ISP capabilities. So far pin 5 is indeed not connected and pin is indeed ground.

There is a jumper block by the way, at the front edge. My model has (as seen from the white dot) only the second and third position jumped.


The remaining two headers on the topside at the edge (5 pin and 4 pin single row) seem pretty close to the PIC on the other side, but on that same side there is a smaller header just next to the PIC which leads me to believe the top rows aren't programming headers.

In the meantime I have spotted support for the Marvell chip in both FreeBSD and Linux (DSA mode). From a Debian Live environment I didn't get DSA to run because Debian compiles kernels without DSA support. Maybe an OpenWRT build does have DSA. I've also found that MDIO tools do see the bus on the Intel NIC (the 1st NIC), but cannot access it reliably. A fire-and-forget MDIO tool can, and works similar to dell's re-packaged vep1400-mdio-tool.

I have also managed to get the PHY and MAC to behave with pure MDIO commands which leads me to believe that only I2C crosses the CPLD, which in turn means the SFP ports require the CPLD, but the copper ports do not.

 

[Ralph_IT]

[...]
Next step was installing Proxmox following their guide. All worked until the reboot after the pve-kernel-5.15 installation.
If I selected the debian kernel it booted fine, but choosing the pve-kernel meant that console was flooded by error "acpi fpdt: duplicate resume performance record found" which looped ad eternum.
The only reference I could find was an answer in Proxmox forum's from October 2022 stating that a BIOS downgrade to the original one fixes this problem.
Got nothing to loose so there I went and, indeed, it fixed the problem. Maybe this approach is too radical, but didn't find anything better.
Right now I have a Proxmox installation that works, with the gui available, ssh enabled and fully functional.

Next thing is to upgrade BIOS to last version and check if error comes back.

**NOTICE TO NAVIGATORS**
I strongly advice against my previous advice, as you can end with a non-working BIOS and not realize it until next reboot.

When I downgraded and later upgraded the BIOS something went wrong, but I didn't notice it since the system was able to reboot without issue multiple times.

Things went astray when I plugged it back some weeks later: No output from serial console, fixed red led and rebooting every 20 seconds or so.
Using the reset button in the back didn't help neither, so out of desperation I open up the case and began to fiddle with the black buttons that are next to the ethernet ports, and found this:
- If I pressed the one who is close to the NICs, nothing happened (or at least it did not change any behaviour).
- If I pressed the farthest one, unit booted from what it seemed and alternate BIOS, as if these units got two.
- If I pressed both for 10 seconds, unit rebooted.

Unit started but never booted on first try, giving always an RTC error. After more than 10 minutes waiting, unit booted fine and Proxmox was loaded without problem, even rebooted fine. So things were fixed, right? Well, as long as you don't pull the plug. Each time I remove the power cord the issue came back and nothing helped except pressing the black button again.

Since it spitted an RTC error, my first try was changing the battery, but it didn't fix anything.
Then I paid more attention to what the console was saying: It couldn't boot from BIOS v3.48 after some tries and then switched to v3.50, which booted very slowly but fine.

So I entered DIAG-OS with the intention of flashing again the latest firmware and I saw the option to flash also the Nvme BIOS, which was on v3.48.
Once I flashed **both** the unit began to work again flawlessly.

Summing up: It seems I corrupted the BIOS with the firmware downgrade and it is mandatory to have physical access to the unit to fix the issue, so keep this in mind before doing it.

Edit: Typos

 

[Brood]

**NOTICE TO NAVIGATORS**
I strongly advice against my previous advice, as you can end with a non-working BIOS and not realize it until next reboot.

I've checked and from the photos, they all seem to have dual bios... Is this on a VEP1400 or VEP1400-X varient that you had this issue on? I bricked my 610(VEP1400) bios and was able to recover it by reading the rear bios chip and reflashing the front one...

@oneplane has been making huge strides regarding the 610 (vep1400) he was working on. He was also lucky as his unit can with the watchdog already disabled... I on the other hand was not that lucky and my vep1400 is still rebooting like clock work and I was unable to stop it from happening.

I also don't know which is a suitable diagnostic os to load on the 610 (vep1400)

Has anyone found a suitable bios and or diagnostics os for the non x Vep1400 variants or a way to the watchdog as part of the PFsense install/boot?

 

[oneplane]

They all should have two, and I've spotted two ATML devices (SOIC8 it seems), which might be small EEPROMs if it refers to Atmel.
The PIC is used to take care of the buttons (reset on the back, two more inside) and if I've traced the pins correctly it also uses the jumper block.

This would make sense since the boot selector UEFI payload talks to the PIC as well, and the flags change depending on which ROM was used. What I don't yet understand is why my dumps and other people's dumps aren't identical. Perhaps the FIT/Flash Descriptor is different because it marks one as primary and one as secondary.

As a sidenote, the CPLD is actually a normal FPGA, but Dell appears to still refer to it as a CPLD. I have disassembled the vmetool and updatetool, but it appears both don't have standard backup facilities built in, or at least not with a normal naming scheme. There are I2C, SPI and JTAG interfaces to name a few, and pif/piffind.py at master · bugblat/pif contains some code which shows that this should actually work. The FPGA is on I2C address 31, but I'm not sure if that is the real interface or a simulated interface. The code also specifically refers to the XO2-1200HC that is on the board, so that's neat. On the VEP devices the memory writes are buffered via some sort of sideband interface, I'm not sure how to interface with that, but I2C might be enough.

 

[Brood]

They all should have two, and I've spotted two ATML devices (SOIC8 it seems), which might be small EEPROMs if it refers to Atmel.
The PIC is used to take care of the buttons (reset on the back, two more inside) and if I've traced the pins correctly it also uses the jumper block.

This would make sense since the boot selector UEFI payload talks to the PIC as well, and the flags change depending on which ROM was used. What I don't yet understand is why my dumps and other people's dumps aren't identical. Perhaps the FIT/Flash Descriptor is different because it marks one as primary and one as secondary.

As a sidenote, the CPLD is actually a normal FPGA, but Dell appears to still refer to it as a CPLD. I have disassembled the vmetool and updatetool, but it appears both don't have standard backup facilities built in, or at least not with a normal naming scheme. There are I2C, SPI and JTAG interfaces to name a few, and pif/piffind.py at master · bugblat/pif contains some code which shows that this should actually work. The FPGA is on I2C address 31, but I'm not sure if that is the real interface or a simulated interface. The code also specifically refers to the XO2-1200HC that is on the board, so that's neat. On the VEP devices the memory writes are buffered via some sort of sideband interface, I'm not sure how to interface with that, but I2C might be enough.

I wonder if the jumpers on the back can disable the watchdog by default. Where are your jumpers? Are your jumpers in the same position as mine?

 

[Brood]

I wonder if the jumpers on the back can disable the watchdog by default. Where are your jumpers? Are your jumpers in the same position as mine?


View attachment 28975

also what is your BIOS, CLPD & PIC software revisions?

 

[oneplane]

also what is your BIOS, CLPD & PIC software revisions?

BIOS version:
3.43.0.9-2

CPLD version:
0.20

PIC version:
0.26

Jumpers are configured the same as yours.

 

[Ralph_IT]

I've checked and from the photos, they all seem to have dual bios... Is this on a VEP1400 or VEP1400-X varient that you had this issue on? I bricked my 610(VEP1400) bios and was able to recover it by reading the rear bios chip and reflashing the front one...

It was on an X version (Edge 680)

 

[oneplane]

Digging around a bit more, it appears vmetool in DiagOS is actually a packaged version of the Lattice ispVM embedded programmer, intended for purposes just like this. ProgrammingToolsUserGuide31.pdf Dell puts some of the lattice code inside their own little toolset and uses the same default_vme_list.cfg for pretty much all VEP1400 non-X SKUs. The file has some not-very-imaginative format:

# TDI | TCK | TMS | WE | TRST | TDO | SEL_PIN | CPU_FREQ | g_CoresiIspPins | g_SussiIspPins | g_WEAssertLevel | Interface | Bar_Addr | Jtag_Reg | Image_Name_Format
7 | 8 | 5 | 18 | -1 | 6 | -1 | 356 | 0x00000000 | 0x00000000 | 0 | CPU | 0xfd000000 | - | vep1400

# CPU | SIDEBAND_WE | SIDEBAND_JTAG
DENVERTON | 0xc20000| 0xc50000
# GPIO NO. | SIDEBAND | OFFSET
5 | SIDEBAND_JTAG | 0x570
6 | SIDEBAND_JTAG | 0x578
7 | SIDEBAND_JTAG | 0x580
8 | SIDEBAND_JTAG | 0x5c8
18| SIDEBAND_WE   | 0x420

And inside vmetool they have a parser that reads this, and then uses the GPIO numbers to configure how the programmer should access the chip.
There is a big GPIO register that gpiotool can access which appears to have a bunch of pre-defined settings from /etc/dn/ (which contains all sorts of files for the hardware and internal buses as well as alternate SKUs -- I haven't figured out how they map each SKU yet)

They are essentially bit-banging JTAG over GPIO, the same way you'd do that using a Raspberry Pi (albeit with some hardware support).

TDI, TCK, TMS, TDO are GPIOS, and WE (write enable I presume) is some sort of other range (0xc20000), but also on the same GPIO controller.

Looking at that guide from lattice, the CPU-to-FPGA + Header seems exactly what Dell did on the hardware here. I think I still have a JTAG device around here somewhere, and otherwise I'll have to find either my Bus Pirate, any Raspberry Pi or a TUMPA which should be in a bin of dev tools somewhere.

Alternatively, some sort of software that knows what the offsets mean in combination with a JTAG tool could do it all using existing hardware since it's all wired up anyway. I2C itself doesn't seem to be an option, it appears that it only interfaces with the functions the FPGA provides (reset button and LEDs mostly). I haven't figured out if the FPGA is connected to the switch ASIC, but it wouldn't surprise me; that would be the whole benefit of this thing since routing that data over the CPU makes the FPGA pointless. A boundary scan should show what is connected, and perhaps Lattice Diamond or the Xilinx tool (also supports this FPGA!) can tell me if any special protocol blocks are in use and where.

As for the two extra EEPROMS on the board: one is the system ID ROM and the other is the RAM SPD ROM, so those aren't all that interesting. The system ID rom contains a bunch of TLV data describing the model, serial number, service tag etc.

Updated the 8-pin header a few posts up; turns out ping 8 is VCC and pin 1 is some logic pin (around 1.1v).
Measured the 4 pin header on the front, smells like UART to me (pin1 is marked with a dot):

1 = 3.3v
2 = TX? (hovers around 3.3v)
3 = RX?
4 = GND

I'll hook up something to check it out. Perhaps it just mirrors whatever us already connected on the mini-USB-B port on the back.

Edit: no luck, no data going in our out, maybe I'm wrong and it's a different kind of port. It definitely is all 3v3 levels, but it's not ttyS1 and ttyS0 is the USB-serial one and it's not that either. ttyS2 just hangs and ttyS3 has I/O errors (but I'm assuming that's the Intel Management Engine or the SPS version).

Time to bit-bang some JTAG! Found a Pi available so I'll see if that gets us the FPGA bitstream.

 

[oneplane]

I think I just successfully dumped the entire FPGA (which Dell still calls the CPLD). Turns out that all measurements and assumptions checked out, the port on the side (near the WiFi module) is a directly attached JTAG. Since Lattice Diamond is free and I have a TIAO FT2323H, it's just a matter of connecting a few wires and now you can do whatever you want to the chip.

The bitstream seems to be complete enough to make sense, but I haven't yet dared to write it back to the device to validate. I want to make sure what I extract is usable from DiagOS as well so anyone who doesn't have an external JTAG interface can just use whatever Dell happens to share.

This is a revision 000 board from the VEP1400 (non-X) series, white case, Dell-branded VEP1400 on the front. I don't think the FPGA is wired up differently on the Edge series considering it uses the same C3000 SoC and Marvell Switch.

Fun fact, the device needs to be on for JTAG to work, and if you keep track of dmesg in Linux while doing it, you can see the CPU being very unhappy about the JTAG bus getting tickled and the FPGA restarting (ultimately causing a device reboot). Probably because the Lattice Diamond FPGA software issues a reset after the read.

 

[oneplane]

To my surprise, most Linux-based appliance-like software distributions have DSA disabled This means that while native configuration for the network ports on VEP1400 (non-X) models is available, it's just not turned on. Even nightly builds from VyOS and OpenWRT don't have it by default. OpenWRT does have it for device-specific builds, but for x86 they aren't enabling it by default.

I'm currently re-building VyOS to see how hard it would to be make a custom kernel; it essentially just needs 2 or 3 config flags turned on to make it all work.

In the meantime, the vep1400-mdio-tool or whatever it's called does work fine outside of DiagOS, so even on standard distributions this can be used to configure the switch. The LEDs are configured over I2C, but the configuration is persistent it seems, so once it's configured correctly it doesn't just randomly reset and the LEDs work. For the SFP power control I'm not entirely sure, but that's also all just standard I2C. Even BIOS chip selection is I2C based.

I have to clean the FPGA bitstream, DiagOS image and BIOS files so my personal info isn't in there, but other than the PIC we now have a complete set to turn any VEP1400 box into whatever we want.

 

[Brood]

@oneplane thank you for your efforts. Its great work. Does your DiagOS have the update files in for the PIC, BIOS and CPLD(FPGA)? As it seems that the edge version has the dreaded watchdog that keeps rebooting the system

 

[Brood]

Dell-branded VEP1400

What comes up when you put your dell service code into the dell website for drivers?

 

[oneplane]

It doesn't come up at all, presumably because it's geo-restricted. The board ID however returns VEP1400 (not Edge). Dell of course acknowledges it exists via their support mail but keeps telling me they only support the hardware, not the software, and the vmware has the stuff I need. This does sound extra dumb when the service request I sent explains that it's not about the VeloCloud embedded OS, but about the firmware and DiagOS, both which are Dell-owned, Dell-built, Dell-installed at the Dell factory, ant not available to VMWare at all. They do offer replacements, so I could return it to them and have it replaced. But that doesn't help with anything and I doubt I'd get one that is different than what I already have.

You can also just search for VEP and Edge sales and take the Service Tag from the pictures until you get a hit on the dell site with an active service subscription and use that in the support request. Like any large bureaucracy, Dell doesn't care about the actual request, they just care about getting an active Service Tag.

As for the DiagOS: no it doesn't have any update package, but it does have many board ID and SKU device trees so it's compatible with practically the entire non-X VEP line. This is the same as the X-version of the VEP line where DiagOS has the board IDs and SKUs for all VEP-X models embedded in there.

What I'm currently doing is converting the FPGA dump into a JED and VME file so it works with Dell native tools, same for the BIOS dump, I'm seeing if I can package it into a AFU-compatible image. DiagOS as-is already works on VEP and Edge models alike, so the next step is getting the BIOS and FPGA packages or files ready to deploy so anyone can use them without JTAG hardware. Even without that, the anonymised DiagOS can be used to read the TLV from the board EEPROM so you can verify the board ID and VEP lineage. You can also just run it and see if it shuts down. There are multiple timers, current sensors and temperature sensors that all influence an automatic shutdown or reboot, not just a UEFI WDT and CPLD WDT.

Edit: here's what I was thinking we might do:

1. Use a sanitised copy of my DiagOS, you can boot it via USB for example, it is UEFI enabled (I'll post a link when I can)
2. Check if the watchdog still triggers while inside DiagOS
3. If it doesn't trigger, check what the TLV data from the ID EEPROM is so we can do some comparison
4. Check if MDIO and Persistent-Net works the same as on my unit
5. Check if the VME file for the CPLD matches what vmetool on your unit says
6. Check if the BIOS file matches what updatetool says
7. Check gpiotool and pltool to see if the SKU detection sees all the correct inter-chip communication

If it checks out, upgrade the CPLD and BIOS.

 

[Brood]

Edit: here's what I was thinking we might do:

1. Use a sanitised copy of my DiagOS, you can boot it via USB for example, it is UEFI enabled (I'll post a link when I can)
2. Check if the watchdog still triggers while inside DiagOS
3. If it doesn't trigger, check what the TLV data from the ID EEPROM is so we can do some comparison
4. Check if MDIO and Persistent-Net works the same as on my unit
5. Check if the VME file for the CPLD matches what vmetool on your unit says
6. Check if the BIOS file matches what updatetool says
7. Check gpiotool and pltool to see if the SKU detection sees all the correct inter-chip communication

If it checks out, upgrade the CPLD and BIOS.

Sounds like a plan. I have much to learn about exploring systems like this and bending them to my will

 

[oneplane]

So using AfuEfi64 from the UEFI shell one can just do AfuEfix64.efi backup.rom /O and it just does a backup for you.
I'm attaching it here so you can try it out if you want to. It doesn't handle Dell's concept of having two flash devices, but it might be enough for an interesting try-out. As far as I can tell the CPLD actually controls which one of the flash devices is primary, and the reset button can be used (with various durations) to modify it.

This ROM file is from a VEP1400 board, model 000, BIOS ID 0ACHI032, dumped using Aptio_V_AMI_Firmware_Update_Utility (via: Custom UEFI/BIOS - Aptio & AMBIOS) from the UEFI shell.

Download Data package from May 21st.

Size of the data package: 3.31 MB. Free transfer of up to 6 GB of photos, videos and documents. Send large files via email or a link to share. No registration, no ads, just simple file sharing!

filetransfer.io

It does appear to be smart enough to do BIOS ID verification. AfuEfix64.efi is capable enough to read the current BIOS ID stand-alone, as well as read the file's BIOS ID. The Aptio V has a built in UEFI-shell, and can read USB drives with GPT and an ESP (EFI System Partition).

To try this out:

1. Create a valid USB drive, I do that with gdisk or cfdisk but you can use whatever you want, as long as it is UEFI compatible (GPT, ESP)
2. Mount the ESP (it is supposed to be FAT)
3. Copy the rom and AfuEfix64.efi onto it
4. Sync and unmount and unplug, then plug it into your VEP
5. Boot your VEP1400 based system with the serial console attached and go to BIOS settings when prompted
6. On the last page you can find the boot override, pick the UEFI shell (so not your USB drive)
7. The UEFI shell will show you a bunch of storage devices, at least one FS, probably more than one. The trick is to figure out which one is the USB drive you plugged in.

If you have two drives, say the eMMC or SATA drive and your USB drive and both have an ESP, you might have FS0: and FS1: but it might not always end up in the same order.

Maybe just trying both is the best method, the UEFI shell does have tab-completion.

8. Switch to the FileSystem (i.e. FS1) "FS1: <enter>"
9. 'dir' to get the contents, which might be cut off because the wise men at the BIOS programming company made the serial console 80x25
10. If you are in the right place you might see your directory/files, otherwise you might have gone to the EDA-DIAG drive instead, switch to FS0 in that case

Now you can use the AFU tool and the ROM backup to upgrade your device. The AFU tool has a help page which should be plenty to get you going.
I tried to run it on mine but it complained I'm already at the same version (well duh). I'll have to play with the force options or get a second unit to do that.

The previous versions of VeloCloud hardware (the somewhat swanky 5x0 models) appear to have the watchdog in the PIC, but enabled via the BIOS. If the BIOS doesn't turn the watchdog on, it never triggers. Once I have dumped the PIC for my board as well we would have the most complete package ever.

 

[Brood]

I've tested the pins on the top behind the heatsink and I can confirm that they are the ICD connection point for the PIC.


The pinout is as follows:



I've managed to connect and power the pic from the ICD3 but it kicks up a error when trying to read it with the device in a off state.



I need to try and inject 3.3V into the system header while trying to read it as the ICD doesn't seem to have enough grunt to power the PIC up when connected to the programming connector

Edit: I've also tried with the machine booted but once you try to read the image of PIC it reboots the system so I will either need to pull it off the board to read it or find a way to inject the 3.3v but my tools are limited that I have on hand.



So I can see 4 ways forward on the PIC...
1. remove it from the board to try and dump the firmware- not ideal as I do not have a hot air station.
2. Lift the VDD pin and connect directly to that and try to pull the data out that way - sill not ideal as it could damage the board.
3. Dump the firmware with some of the inbuilt tools - way out of my area of expertise
4. Inject 3.3V into the 3.3v rail and try to read out the pic when powered externally but the macine still off - Has potential but I do not have a bench supply to do that...

 

[oneplane]

I've tested the pins on the top behind the heatsink and I can confirm that they are the ICD connection point for the PIC.
View attachment 29119

The pinout is as follows:

View attachment 29120

I've managed to connect and power the pic from the ICD3 but it kicks up a error when trying to read it with the device in a off state.

View attachment 29117

I need to try and inject 3.3V into the system header while trying to read it as the ICD doesn't seem to have enough grunt to power the PIC up when connected to the programming connector

Edit: I've also tried with the machine booted but once you try to read the image of PIC it reboots the system so I will either need to pull it off the board to read it or find a way to inject the 3.3v but my tools are limited that I have on hand.

View attachment 29126

So I can see 4 ways forward on the PIC...
1. remove it from the board to try and dump the firmware- not ideal as I do not have a hot air station.
2. Lift the VDD pin and connect directly to that and try to pull the data out that way - sill not ideal as it could damage the board.
3. Dump the firmware with some of the inbuilt tools - way out of my area of expertise
4. Inject 3.3V into the 3.3v rail and try to read out the pic when powered externally but the macine still off - Has potential but I do not have a bench supply to do that...

Good find! The other pins (not soldered on your model) are probably either a serial port connected to the PIC or the header for the LEDs that go behind the front panel logo on SD-WAN/Velo branded boxes.

Edit: maybe this is what the jumpers are for? Disconnecting Vcc and GND from he PIC... I'll see if I can find out with a multimeter. I also know the PIC comes with a bootloader and separate runtime application, and it needs a machine reboot to switch from one mode to another, which means the startup mode is probably managed by the CPLD? In any case, this means that reading it will be easiest with either the machine off, or with the PIC in bootloader mode while it is on.

If you have the time, check the following options:

1. Disabling the PIC watchdog via I2C, a Live Linux over USB should be plenty fast in booting before the WDT kicks in

2. Flashing the BIOS backup, or checking the BIOS ID using Afu, if the ID is the same as mine it should work

As for those with a broken CPLD: the bitstream is ready to test, so hit me up if I need to write some instructions for that.

Fun fact, the MCLR pin is indeed GPIO-controlled, GPIO mapping has a specific pin for it:

Spoiler: Big XML list of GPIOs

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="gpio-config.xsl"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="gpio-config.xsd">
<platform>VEP1400</platform>

<gpio>
     <gpio-chip>0</gpio-chip>
     <gpio-bits-delimiter>256</gpio-bits-delimiter>
     <gpio-name>CORE-GPIO</gpio-name>
     <gpio-interface>CORE</gpio-interface>
     <gpio-0map>0</gpio-0map>
     <gpio-bit>
          <bit>9</bit>
          <name>BOOT_OK</name>
          <gpio-direction>OUT</gpio-direction>
          <gpio-active>HIGH</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>10</bit>
          <name>INT_88E6190</name>
          <gpio-direction>IN</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>11</bit>
          <name>GLB_RESETn</name>
          <gpio-direction>IN</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>12</bit>
          <name>CPU_GPIO_12</name>
          <gpio-direction>OUT</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>0</val>
     </gpio-bit>
     <gpio-bit>
          <bit>15</bit>
          <name>RST_CPU_88E6190_N</name>
          <gpio-direction>OUT</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>0</val>
     </gpio-bit>
     <gpio-bit>
          <bit>18</bit>
          <name>CPLD_WE</name>
          <gpio-direction>OUT</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>27</bit>
          <name>SSD_MODULE_PRESENT_N</name>
          <gpio-direction>IN</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>39</bit>
          <name>EN_USB3_PORT1</name>
          <gpio-direction>OUT</gpio-direction>
          <gpio-active>HIGH</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>40</bit>
          <name>EN_USB3_PORT2</name>
          <gpio-direction>OUT</gpio-direction>
          <gpio-active>HIGH</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>41</bit>
          <name>THERMAL_INT</name>
          <gpio-direction>IN</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>43</bit>
          <name>USIM2_DETECT</name>
          <gpio-direction>OUT</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>44</bit>
          <name>USIM1_DETECT</name>
          <gpio-direction>OUT</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>80</bit>
          <name>POE_xSystem_ok</name>
          <gpio-direction>IN</gpio-direction>
          <gpio-active>HIGH</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>99</bit>
          <name>WIFI_MODULE_PRESENT_N</name>
          <gpio-direction>IN</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>100</bit>
          <name>PIC_PRG_MCLR</name>
          <gpio-direction>OUT</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>0</val>
     </gpio-bit>
     <gpio-bit>
          <bit>120</bit>
          <name>BOOT_WDT_EN</name>
          <gpio-direction>OUT</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>1</val>
     </gpio-bit>
     <gpio-bit>
          <bit>151</bit>
          <name>USIM2_CD</name>
          <gpio-direction>IN</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>0</val>
     </gpio-bit>
     <gpio-bit>
          <bit>152</bit>
          <name>USIM1_CD</name>
          <gpio-direction>IN</gpio-direction>
          <gpio-active>LOW</gpio-active>
          <val>0</val>
     </gpio-bit>
</gpio>
</config>