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

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

Brood

Member
Apr 15, 2023
58
9
8
I've done some more work and I extracted the VEP1400-X-BIOS-3.48.0.9-19_ufw 2.3_External which i downloaded from the dell site. I managed to identify the the watchdog similar to above but I had more success to extract the IFR data It looks like there are multipe bits referring to it... see the IFR information below:

Code:
Form FormId: 0x330, Title: "Internal Pwr Loss Event Setup"
        Subtitle Prompt: "", Help: "", Flags: 0x0
        End
        GrayOutIf
            EqIdVal QuestionId: 0x2BB, Value: 0x0
                EqIdVal QuestionId: 0x2BB, Value: 0x1
                Or
            End
            CheckBox Prompt: "SoC Pwr loss support", Help: "enable internal detection of ADR entry instead of a CPLD", QuestionFlags: 0x10, QuestionId: 0x2C6, VarStoreId: 0x1, VarOffset: 0x292, Flags: 0x0, Default: Disabled, MfgDefault: Disabled
            End
        End
        CheckBox Prompt: "PMC reset", Help: "Notify when global reset because of SMBUS Slave pwr down; CF9 w/global reset; Host partition timeout w/Promote to global reset; Sx entry timeout", QuestionFlags: 0x10, QuestionId: 0x2C7, VarStoreId: 0x1, VarOffset: 0x294, Flags: 0x0, Default: Disabled, MfgDefault: Disabled
        End
        CheckBox Prompt: "Power Button Override", Help: "Notify when Power Button Override", QuestionFlags: 0x10, QuestionId: 0x2C8, VarStoreId: 0x1, VarOffset: 0x297, Flags: 0x0, Default: Disabled, MfgDefault: Disabled
        End
        CheckBox Prompt: "ME Pwr Button Override", Help: "Notify when ME initiated Power Button Override", QuestionFlags: 0x10, QuestionId: 0x2C9, VarStoreId: 0x1, VarOffset: 0x298, Flags: 0x0, Default: Disabled, MfgDefault: Disabled
        End
        CheckBox Prompt: "ME WDT", Help: "Notify when ME watchdog timer expire", QuestionFlags: 0x10, QuestionId: 0x2CA, VarStoreId: 0x1, VarOffset: 0x299, Flags: 0x0, Default: Disabled, MfgDefault: Disabled
        End
        CheckBox Prompt: "ME reset", Help: "Notify when ME initiated global reset", QuestionFlags: 0x10, QuestionId: 0x2CB, VarStoreId: 0x1, VarOffset: 0x29A, Flags: 0x0, Default: Disabled, MfgDefault: Disabled
        End
        CheckBox Prompt: "PMC WDT", Help: "Notify when PMC watchdog timer expire", QuestionFlags: 0x10, QuestionId: 0x2CC, VarStoreId: 0x1, VarOffset: 0x29C, Flags: 0x0, Default: Disabled, MfgDefault: Disabled
        End
        CheckBox Prompt: "ME uncorr Error", Help: "Notify when ME uncorrectable error", QuestionFlags: 0x10, QuestionId: 0x2CD, VarStoreId: 0x1, VarOffset: 0x29D, Flags: 0x0, Default: Disabled, MfgDefault: Disabled
        End
        CheckBox Prompt: "SYS_PWROK", Help: "Notify when SYS_PWROK failure", QuestionFlags: 0x10, QuestionId: 0x2CE, VarStoreId: 0x1, VarOffset: 0x29E, Flags: 0x0, Default: Disabled, MfgDefault: Disabled
        End
        CheckBox Prompt: "PMC parity error", Help: "Notify when PMC parity error", QuestionFlags: 0x10, QuestionId: 0x2CF, VarStoreId: 0x1, VarOffset: 0x2A0, Flags: 0x0, Default: Disabled, MfgDefault: Disabled
        End
        CheckBox Prompt: "Return power", Help: "Power up ~4 sec after ADR entry", QuestionFlags: 0x10, QuestionId: 0x2D0, VarStoreId: 0x1, VarOffset: 0x2AF, Flags: 0x0, Default: Disabled, MfgDefault: Disabled
        End
    End
I can see its referring to a ME WDT and a PMC WDT... both disabled by default.

Fingers crossed that there is the same in the Edge 610... My CH341A is till on the way with a eta on the 14th of may... does anyone else have a unmodified edge 610 and has a ch341a readily avaiable to do a bios dump so that I can see if I can make some further progress on trying to idenify the correct bios bits to permanently turn off the watch dog without needing a bios reflash
 

Brood

Member
Apr 15, 2023
58
9
8
Good and Bad news... my CH341A finally arrived... however in trying to dump the bios it seems that I managed to brick the 610... I just have a solid read light at the back and sfp1 rightside led green... they stay on for around 10 seconds and then turn off for 3 seconds and it just repeats...

Did anyone else have any luck with obtaining a bios image for the edge 610 / VEP1400

******UPDATE*****

There is a second Bios chip on the back. So everyone who bricked their bios by flashing the VEP1400-X bios... you can revert to the previos bios by grabing a dump of the rear bios and all of your data should be retained...

1683661415484.png

these dip switches migh even be a way to enable the rear bios chip... further investigations on going...
 
Last edited:
  • Like
Reactions: tasort

Brood

Member
Apr 15, 2023
58
9
8
@oneplane I look forward to seeing what you come up with... as I dont have the kit to dump the pic and clpd... I do wonder if the header next to the image in my post above links to the bios. I didn't test for that.
 

oneplane

Well-Known Member
Jul 23, 2021
845
484
63
There are multiple SPI flash chips by the way, and they might not be redundant copies, just different purposes (like separate CPLD SPI flashes, one for the system firmware, another for some other embedded controller.. who knows).
 

Brood

Member
Apr 15, 2023
58
9
8
There are multiple SPI flash chips by the way, and they might not be redundant copies, just different purposes (like separate CPLD SPI flashes, one for the system firmware, another for some other embedded controller.. who knows).
They are a redundant copy... as I corrupted the one next to the wifi card to the point that it will no longer boot... I then used the dump from the one on the rear to reflash the front one and it came back to life...
1683664077726.png

I also saw in the boot that it states loading off primary bios or something along those lines... which backs up the multiple bios images on board
 
Last edited:

oneplane

Well-Known Member
Jul 23, 2021
845
484
63
Nice! This does make me wonder where the other chips are located, perhaps in SOIC16 chips elsewhere (haven't seen any other 8-pin flashes besides the two you mentioned so far).
 

Brood

Member
Apr 15, 2023
58
9
8
Nice! This does make me wonder where the other chips are located, perhaps in SOIC16 chips elsewhere (haven't seen any other 8-pin flashes besides the two you mentioned so far).
My thoughts would be that they are embedded in the CPLD and PIC...

I think this is the PIC:
1683666544005.png

And the CLPD is here:

1683666593697.png
 

oneplane

Well-Known Member
Jul 23, 2021
845
484
63
I'll first log what I have here in terms of hardware and firmware:

  • White Dell EMC branded VEP1400 (non-X)
  • CPU Signature 506F1
  • Aptio Core Version 5.13
  • UEFI 2.6; PI 1.4
  • Project Version 3.43.0.9-2
  • Build Date and Time 09/28/2018 02:20:06

So it's a pretty old version AFAICT.

Other aspects:

  • 4GB DDR4
  • 16GB eMMC storage with DIAG-OS partition
  • Firmware reports X553 10GbE backplane (4x) but ports report 1GbE max (so I suspect the PHY or the CPLD limit this?)

The Diag-OS that came with this unit is (according to the banner):

Diag OS version VEP1400_DIAG_OS_3.43.3.81-5

Build date/time Wed Sep 26 05:06:11 PDT 2018
Build server netlogin-eqx-02
Build by thsu
Kernel Info:
Linux 4.9.30 #8 SMP PREEMPT Wed Sep 5 22:42:12 PDT 2018 x86_64 GNU/Linux
Debian GNU/Linux 8

According to dmesg, there are two watchdog timer drivers loaded:
  • [ 0.897843] IPMI Watchdog: driver initialized
  • [ 2.477633] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11

When probing /sys/module/ipmi_watchdog/parameters/ it does appear this driver is active, but I haven't tried changing some settings to see if that resets the machine.

Checking /opt/dellemc/diag/README it appears the Diag Tools is indeed at least 3.x, the first few lines have two empty change logs and version ranges for some reason, and then at 1.10 it actually shows a changelog:
Code:
Version 3.xx.4.2 Diag Package contains:

Version 3.xx.4.1 Diag Package contains:

The path to the diagnositcs applications has changed to reflect the correct naming structure for Dell diags
The Versioning of the dn diags tools debian package has changed to match closer to Dell versioning.

Version 1.10 Diag Package contains:
Dell Diag /opt/ngos/bin/edatool version 1.4, package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/cputool - version 1.1 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/fantool - version 1.5 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/gpiotool - version 1.4 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/i2ctool - version 1.5 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/ledtool - version 1.0 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/lpctool - version 1.0 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/memtool - version 1.5 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/nputool - version 1.0 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/nvramtool - version 1.5 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/opticstool - version 1.0 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/pcitool - version 1.5 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/phytool - version 1.1 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/pltool - version 1.5 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/psutool - version 1.4 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/rtctool - version 1.1 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/smbiostool - version 1.1 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/storagetool - version 1.1 package 1.10 2015/03/24
Dell Diag /opt/ngos/bin/temptool - version 1.4 package 1.10 2015/03/24
The included updatetool shows the same devices as the VEP-X:
Code:
Device name: BIOS
    Device Region:
        1 : primary
        2 : backup
    Support operation:
        update device
        Read operation
        show device version
        show flash info

Device name: CPLD
    Support operation:
        update device
        show device version

Device name: PIC
    Support operation:
        update device
        show device version

Device name: cc26x0
    Support operation:
        update device
        show device version
With versions:

Code:
BIOS version:
3.43.0.9-2

CPLD version:
0.20

PIC version:
0.26

cc26x0 version:
User Revision Number: 0x0002
BLE Stack Version: 02.02.02
Stack Build Version: 0x196E
Looking at the config some more I've spotted a vep1400 MDIO Tool which apparently sets up a bunch of hardware VLANs, which is probably also why some people reported various port configurations behaving in odd ways. It also has two bash scripts to reconfigure and de-configure the ports. As-is, this device came with:

- eth0
- eth2
- eth3
- eth0.1
- eth0.2
- eth0.3

This likely means that the interfaces are split across a few groups, and a bundle of tagged access ports (both on the inside and the outside). Probably for their edge or SASE service offerings, which we couldn't care less about.
 
Last edited:
  • Like
Reactions: Brood

Brood

Member
Apr 15, 2023
58
9
8
Nope, uptime is over 15 minutes (I'm inside DiagOS at the moment)
My 610 is ok and stay up when i'm in the shell but it will reboot every 5 mintues if you are in the bios (it didn't come with the diag os) and have the shell and the VMware SD-Wan software on it... the 640 stopped the rebooting in the bios after the vep1400-x bios/clpd/pic update.
 

oneplane

Well-Known Member
Jul 23, 2021
845
484
63
My 610 is ok and stay up when i'm in the shell but it will reboot every 5 mintues if you are in the bios (it didn't come with the diag os) and have the shell and the VMware SD-Wan software on it... the 640 stopped the rebooting in the bios after the vep1400-x bios/clpd/pic update.
I'll pop back into the UEFI setup screen and see if it resets. It is an E42W family device.

Edit: no resets so far, been in the Aptio Setup Utility screen for a while now.
 
Last edited:

oneplane

Well-Known Member
Jul 23, 2021
845
484
63
So after a reboot (it didn't reset by itself) I checked the network interfaces inside DiagOS again, and now I have an additional eth1, and VLAN interfaces in hardware (vlan IDs 4, 5, 6). I'll run the mdio reset tool from DiagOS to see if that cleans it up. I suspect the CPLD is doing this, or that the PIC might have a hand in pre-configuring the network.

Edit: so this does indeed remove the configuration, the ports are back to 'normal' mode.

Code:
/opt/dellemc/diag/bin/vep1400_disable_vlan.sh
mac reg write daddr:0x01 reg:0x07 val:0x0001
mac reg write daddr:0x02 reg:0x07 val:0x0001
mac reg write daddr:0x03 reg:0x07 val:0x0001
mac reg write daddr:0x04 reg:0x07 val:0x0001
mac reg write daddr:0x05 reg:0x07 val:0x0001
mac reg write daddr:0x06 reg:0x07 val:0x0001
mac reg write daddr:0x09 reg:0x07 val:0x0001
mac reg write daddr:0x0a reg:0x07 val:0x0001
mac reg write daddr:0x01 reg:0x08 val:0x2080
mac reg write daddr:0x02 reg:0x08 val:0x2080
mac reg write daddr:0x03 reg:0x08 val:0x2080
mac reg write daddr:0x04 reg:0x08 val:0x2080
mac reg write daddr:0x05 reg:0x08 val:0x2080
mac reg write daddr:0x06 reg:0x08 val:0x2080
mac reg write daddr:0x09 reg:0x08 val:0x2080
mac reg write daddr:0x0a reg:0x08 val:0x2080
mac reg write daddr:0x1b reg:0x06 val:0x0001
mac reg write daddr:0x1b reg:0x05 val:0xb000
mac reg write daddr:0x1b reg:0x06 val:0x0002
mac reg write daddr:0x1b reg:0x05 val:0xb000
mac reg write daddr:0x1b reg:0x06 val:0x0003
mac reg write daddr:0x1b reg:0x05 val:0xb000
mac reg write daddr:0x1b reg:0x06 val:0x0004
mac reg write daddr:0x1b reg:0x05 val:0xb000
mac reg write daddr:0x1b reg:0x06 val:0x0005
mac reg write daddr:0x1b reg:0x05 val:0xb000
mac reg write daddr:0x1b reg:0x06 val:0x0006
mac reg write daddr:0x1b reg:0x05 val:0xb000
mac reg write daddr:0x1b reg:0x06 val:0x0009
mac reg write daddr:0x1b reg:0x05 val:0xb000
mac reg write daddr:0x1b reg:0x06 val:0x000a
mac reg write daddr:0x1b reg:0x05 val:0xb000
Removed VLAN -:eth0.1:-
Removed VLAN -:eth0.2:-
Removed VLAN -:eth0.3:-
Removed VLAN -:eth1.4:-
Removed VLAN -:eth1.5:-
Removed VLAN -:eth1.6:-

Edit2: after the reset, ethool tells me this is the topology:

eth0 and eth1 are the SFP ports, but for some reason the data seems rather messed up (no SFPs plugged in):
Code:
Settings for eth0:
        Supported ports: [ FIBRE ]
        Supported link modes:   Not reported
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Advertised link modes:  Not reported
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: 2500Mb/s
        Duplex: Full
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: umbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes
eth2 and eth3 are copper ports, but also somewhat odd in the ethtool reports:

Code:
Settings for eth2:
        Supported ports: [ FIBRE ]
        Supported link modes:   1000baseKX/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Advertised link modes:  1000baseKX/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: umbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: no
But this is also in line with the other VEP (non-X) reports, where there seems to be a mismatch between physical ports and actual ethernet controllers. This also explains why there is some internal VLAN magic happening, just like some consumer routers do where the LAN ports aren't actual interfaces but rather an internal switch with 1 port going to the SoC for LAN, and 1 separate PHY with a separate port also going to the SoC. This allows the box to have more ports than actual interfaces. I haven't checked if the Intel PCIe devices reported by lspci are actual chips, or are virtual devices used to interface with the C3000 internal MAC. But considering the MDIO tool is used here, I suspect some Intel ethernet SKU is used to do some of this port magic.

DiagOS also comes with 'opticstool', probably because the CPLD layer (?) makes it not possible for ethtool to read the SFP directly. Some random SFPs I had in a drawer do show up correctly (both 1G):

Code:
# opticstool  -x
Show Optics in System
Port #  Name           Status  Type    Part Number      Rev  Serial Number
------  ------------   ------  ------- ---------------  ---  ---------------
   1           SFP 1   PRESENT SFP*    XCVR-010M31       10   LP6xxxxxx703
   2           SFP 2   PRESENT SFP*    QFBR-5766LP                AGSxxxxxxZ
And as https://www.servethehome.com/day-0-with-intel-atom-c3000-getting-nics-working/ describes, the C3000 backplane and port pairing does indeed work this way.

And as confirmed twice earlier, the 88E6190 sits between the C3000 and the actual ports, and the mdio tool is used to configure the relation between the external ports and the internal ones.
 
Last edited:
  • Like
Reactions: Brood

oneplane

Well-Known Member
Jul 23, 2021
845
484
63
I'm going to do a little test to see if the watchdog gets disabled by the OS and a warm reboot doesn't re-enable it. If this also doesn't cause resets I can only conclude that this watchdog is firmware payload specific.

Update: again, no resets. I think this unit simply doesn't do the reset thing, it the PIC or CPLD is involved and isn't configured for resets either.
 
Last edited:

oneplane

Well-Known Member
Jul 23, 2021
845
484
63
I have found at least one additional CPLD watchdog configuration using pltool, but this is not the one that is currently resetting some people's boxes:

Code:
   0xd Watch Dog Register bits:8 RW val:0x21 mask:0xff test:0
         7 Reserved RW 0
      6:4 Watchdog Timer RW 0x2
          0 15 sec
          1 20 sec
          2 30 sec
          3 40 sec
          4 50 sec
          5 60 sec
          6 65 sec
          7 70 sec
         3 Watchdog Enable RW 0
          0 Disable watch dog function
          1 Watch dog counter working
      2:1 Reserved RW 0
         0 Watchdog Timer Punch RW 0x1
          0 The timer is restarted if Watchdog Enable bit is set
          1 No effect on timer function
It does however mean that we appear to have at least 3 watchdogs in 1 box...

Code:
System CPLD 0x31 cpld /dev/i2c-1 (TBD-U#)
   0 Hardware and Board ID Register bits:8 RO val:0 mask:0xff test:0
         7 Reserved RO 0
      6:4 HW Version RO 0
      3:0 Board Type RO 0
          0 VEP1400
          1 VEP1400-64G
          3 VEP1400-4C (C3508)
          4 VEP1400-8C
          5 VEP1400-16C
          6 VEP1400-8CP
          7 VEP1400-4C (C3558)
   0x1 Software Reset Register bits:8 RW val:0xff mask:0xff test:0
         7 Software Force Reset All System RW 0x1
          0 Reset
          1 Normal operation
      6:3 Reserved RW 0xf
         2 Software Reset The Bluetooth Module RW 0x1
          0 Reset
          1 Normal operation
         1 Software Reset The WiFi Module RW 0x1
          0 Reset
          1 Normal operation
         0 Software Reset The LTE Module RW 0x1
          0 Reset
          1 Normal operation
   0x3 PoE Power Enable Register bits:8 RW val:0 mask:0xff test:0
      7:6 Reserved RW 0
         5 Port 6 PoE Power Enable RW 0
          0 No POE Power
          1 POE Power
         4 Port 5 PoE Power Enable RW 0
          0 No POE Power
          1 POE Power
         3 Port 4 PoE Power Enable RW 0
          0 No POE Power
          1 POE Power
         2 Port 3 PoE Power Enable RW 0
          0 No POE Power
          1 POE Power
         1 Port 2 PoE Power Enable RW 0
          0 No POE Power
          1 POE Power
         0 Port 1 PoE Power Enable RW 0
          0 No POE Power
          1 POE Power
   0x4 Fan Interrupt Enable Register bits:8 RW val:0 mask:0xff test:0
      7:1 Reserved RW 0
         0 Fan Alert Interrupt RW 0
          0 Interrupt is disabled
          1 Interrupt is enabled
   0x5 Fan Interrupt Status Register bits:8 RC val:0 mask:0xff test:0
      7:1 Reserved RW 0
         0 FAN Alert Interrupt Status RC 0x1
          0 No Interrupt
          1 Interrupt Occurred
   0x7 System CPLD Debug Revision bits:8 RO val:0 mask:0xff test:0
      7:0 CPLD Revision RO 0
   0x8 CPLD Program Revision Register bits:8 RO val:0 mask:0xff test:0
      7:0 CPLD Revision RO 0
   0xa RJ45 LED Test Register bits:8 RW val:0 mask:0xff test:0
      7:2 Reserved RW 0
      1:0 RJ45 Port LED Test RW 0
          0 Normal operation
          1 All LED of all RJ45 ports to Green color for test
          2 All LED of all RJ45 ports to Amber color for test
          3 All LED of all RJ45 ports off
   0xb CPLD Write Enable Register bits:8 RW val:0x1 mask:0xff test:0
      7:1 Reserved RW 0
         0 CPLD Write Enable RW 0x1
          0 Write protect Disabled
          1 Write protect Enabled
   0xc Module Control Register bits:8 RW val:0x7 mask:0xff test:0
      7:4 Reserved RW 0
         3 LTE Module Dynamic Power Control RW 0
          0 The dynamic power control signal for LTE module is Back off
          1 The dynamic power control signal for LTE module is No SAR back off
         2 LTE Module Disable RW 0x1
          0 Disable LTE module
          1 Not Disabled
         1 WIFI Module Disable RW 0x1
          0 Disable Wifi module
          1 Not Disable
         0 LTE Module Power RW 0x1
          0 Power off
          1 Power on
   0xd Watch Dog Register bits:8 RW val:0x21 mask:0xff test:0
         7 Reserved RW 0
      6:4 Watchdog Timer RW 0x2
          0 15 sec
          1 20 sec
          2 30 sec
          3 40 sec
          4 50 sec
          5 60 sec
          6 65 sec
          7 70 sec
         3 Watchdog Enable RW 0
          0 Disable watch dog function
          1 Watch dog counter working
      2:1 Reserved RW 0
         0 Watchdog Timer Punch RW 0x1
          0 The timer is restarted if Watchdog Enable bit is set
          1 No effect on timer function
   0xe BIOS Select Control Register bits:8 RW val:0 mask:0xff test:0
      7:1 Reserved RW 0
         0 BIOS selection RW 0
          0 Main BIOS
          1 Backup BIOS
   0x10 SFP Port0 Register bits:8 RO val:0x87 mask:0xff test:0
         7 SFP port 0 TX Disable RW 0x1
          0 Enable transmit power
          1 Disable transmit power
      6:3 Reserved RO 0
         2 SFP port 0 TX Fault RO 0x1
          0 Transmitter OK
          1 Transmitter Fault
         1 SFP port 0 RX LOS RO 0x1
          0 SFP port is link up
          1 SFP port is link down
         0 SFP port 0 Transceiver status RO 0x1
          0 SFP Transceiver is presented
          1 SFP Transceiver is not presented
   0x11 SFP Port1 Register bits:8 RO val:0x87 mask:0xff test:0
         7 SFP port 1 TX Disable RW 0x1
          0 Enable transmit power
          1 Disable transmit power
      6:3 Reserved RO 0
         2 SFP port 1 TX Fault RO 0x1
          0 Transmitter OK
          1 Transmitter Fault
         1 SFP port 1 RX LOS RO 0x1
          0 SFP port is link up
          1 SFP port is link down
         0 SFP port 1 Transceiver status RO 0x1
          0 SFP Transceiver is presented
          1 SFP Transceiver is not presented
   0x15 SFP LED Link Status Register bits:8 RW val:0xff mask:0xff test:1
      7:4 Reserved RW 0
         3 SFP Port 0 1G LED control RW 0x1
          0 Port 0 link enable
          1 Port 0 link disable
         2 SFP Port 1 1G LED control RW 0x1
          0 Port 1 link enable
          1 Port 1 link disable
         1 SFP Port 0 100M LED control RW 0x1
          0 Port 0 link enable
          1 Port 0 link disable
         0 SFP Port 1 100M LED control RW 0x1
          0 Port 1 link enable
          1 Port 1 link disable
   0x16 Reset Button Status Register bits:8 RW val:0 mask:0xff test:0
      7:1 Reserved RW 0
         0 Reset button status RW 0
          0 Button low not over five seconds
          1 Button low over five seconds
 

Brood

Member
Apr 15, 2023
58
9
8
@oneplane

It looks like you lucked out on the unit you have... I've dug through the bios dump I made from thhe backup bios to restore the primary bios and it has the same watchdog entries as Watchdog Bios entries from VEP1400-x bios in just a slightly different location. They are also disabled by default. So I'm ruling out the bios being the culprit for the moment and therefore I firmly believe its either the CLPD or PIC responsible for the watchdog reboots...

Currently leaning towards the CLPD being the culprit looking at your findings... Aparently if you buy it from ETB technologies the watchdog seems to be disabled by default.

Was the dell diagnostics already installed on your unit or did you download it from somwhere as it would be usefull to load onto my edge610? Also did you try to boot a linux live disk to see if the watchdog is active if you boot from a usb?

it might be as simple as booting into the dell diagnostics once you have it and to change the variable to disable it.
 

Brood

Member
Apr 15, 2023
58
9
8
I've done some more digging and the Pic on the 610 is located on the bottom (oppisite side to the CPU) on the back edge assuming the RJ45 ports are on the front edge. There is also a header that is suspisiously looking like a programming header directly above the PIC on the board indicated by the 2 and a COM/RS232 port next to it indicated by 1.

1683711876392.png1683713522799.png
The Pic is a PIC16F18345 and it has 14Kb of flash memory and the bin file is 16Kb that is in the vep1400-x firmware... So the 1400-x varient is either using a pic with more internal flash memory as I was not able to find another flash chip on the board or the bin file is stripped down to fit into the 14Kb avaiable during the update as address 0x00000000 to 0x00002470 is just filled with FF so it could quite likely fit when stripped out.

1683711535515.png

as for the lattice CPLD... The JEDEC file in the VEP1400-X bios update for the CPLD is 345Kb and if you open it you can see that the first 1227 lines are config data and the remaining lines starting at 1228 to 2782 seems to be place holders. So that will easily fit in the 245Kb of on chip flash.

Therefore I would say its safe to assume that both the CPLD and PIC programs are loaded directly onto them and that they do not use external flash memory.

I am also wondering if this header migh be the JTAG programming port for the CPLD as its in quite close proximity
1683713671173.png
 
Last edited: