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

[nmpu]

Just to clarify, in the boot menu you may see both UEFI and non-UEFI options for the USB stick containing the DiagOS install. You need to choose the UEFI USB. Of course, in order to see any UEFI boot option, UEFI has to be enabled elsewhere in the BIOS.

I wouldn't panic yet. I don't think anyone has ever confirmed a defective device. I just updated a 640 (Wi-Fi-- not N) which logged i2c retries to the NIC until everything was updated.

What BIOS version came installed? Does the unit reboot if you remain in BIOS for 5 minutes?

 

[frantathefranta]

Just to clarify, in the boot menu you may see both UEFI and non-UEFI options for the USB stick containing the DiagOS install. You need to choose the UEFI USB. Of course, in order to see any UEFI boot option, UEFI has to be enabled elsewhere in the BIOS.

I wouldn't panic yet. I don't think anyone has ever confirmed a defective device. I just updated a 640 (Wi-Fi-- not N) which logged i2c retries to the NIC until everything was updated.

What BIOS version came installed? Does the unit reboot if you remain in BIOS for 5 minutes?

This is the process I boot up the DiagOS installer:
1. Flash the USB according to Dell's instructions: sudo dd if=./diagos-recovery-x86_64-dellemc_vep1400_c3538-r0.3.43.3.81-27.iso of=/dev/sda bs=1M
2. Plug in in to USB1 port on the 640 and then select "UEFI: Lexar USB Flash Drive" from the Save & Exit tab. I've also tried with the "UEFI: Lexar USB Flash Drive, Partition 1" and it boots as well, and gives same results.

3. Try to install to eMMC but it fails the same way each time:

Failure: Unable to install image: /diag-installer-x86_64-dellemc_vep1400_c3538-r0-3.43.3.81-27-2022-12-08.bin
This should be not reachable unless something wrong is there!!!!!

When I'm in the ONIE-RECOVERY shell, I can confirm the system is booted as UEFI.

As to your questions:
* BIOS version: 3.50.0.9-13
* The system does reboot after 5 minutes but I can stop the watchdog using i2cset -y 1 0x22 0 0 b.

Other things I've tried based on reading this thread:
* Updating BIOS/CPLD/PIC using the FW updater in the live USB DiagOS but to no avail.
* Factory reset by holding the outside reset button.
* Trying to switch to a different BIOS slot using the S1 button on the motherboard.
* Holding both S1 and S2 buttons for 10-15 seconds for some kind of reset.

 

[rory]

When you state that you tried "updating the BIOS/CPLD/PIC using the FW updater in the live USB DiagOS but to no avail", did the CPLD update indicate success? It appears to me that the CPLD is at the root of your issues.

 

[frantathefranta]

When you state that you tried "updating the BIOS/CPLD/PIC using the FW updater in the live USB DiagOS but to no avail", did the CPLD update indicate success? It appears to me that the CPLD is at the root of your issues.

Nope, it always fails almost immediately with something like "can't find ./start.sh file". I assume it's something to do with it being a live DiagOS instead of an installed one. I'm trying to install Debian right now to update the firmware that way.

 

[frantathefranta]

I did make progress and have installed DiagOS on a USB (I'll add that process later, but had to uncomment the case statement for installing grub in the install.sh script see picture below). Now I can boot into the DiagOS (in Legacy BIOS mode, not sure if that matters) and when I try to update the firmware, I run into this:

    ===== Cancel the Update Process =====

    Error: Can not find the i2c bus of CPLD

Anyone know what to do about this? It also seems like the issue that prevents me to install DiagOS without tweaking the install script.

EDIT: Also think that only BIOS Slot 2 actually works. Trying to boot from BIOS that starts when pressing the S1 button almost always fails (either just after the POST checks or if I get in the BIOS setup menu, it cannot read any bootable devices).

EDIT2: I did boot from Slot 1 (which takes about 10 minutes) and installed DiagOS to the eMMC (also still had to uncomment the case statement). No improvement when updating firmware,the i2c bus of CPLD is still missing).

 

[nmpu]

@frantathefranta I'm pretty sure the upgrade script needs to run from the /root folder. Can you confirm that's what you're doing? Second, when you run the upgrade, is it followed by interactive? I would attempt to update the BIOS and NVRAM as a first step. Is it possible that you're booting from an old BIOS slot which is out of step with the current CPLD/PIC?

I've managed to get a device in a state where it boots from slot 1, initializes for a long time, (detects some error?), and then boots from slot 2. The only way out is to reinstall the current BIOS with NVRAM update. Once you can successfully boot from the current BIOS, then go back and attempt to update the CPLD and PIC.

 

[frantathefranta]

@frantathefranta I'm pretty sure the upgrade script needs to run from a /boot folder. Can you confirm that's what you're doing? Second, when you run the upgrade, is it followed by interactive? I would attempt to update the BIOS and NVRAM as a first step. Is it possible that you're booting from an old BIOS slot which is out of step with the current CPLD/PIC?

I've managed to get a device in a state where it boots from slot 1, initializes for a long time, (detects some error?), and then boots from slot 2. The only way out is to reinstall the current BIOS with NVRAM update. Once you can successfully boot from the current BIOS, then go back and attempt to update the CPLD and PIC.

This is what I see on when running the update script in DiagOS (on both BIOS slots):

Spoiler: Full output

root@dellemc-diag-os:/boot# ./vep1400x_ufw_2.6 interactive
Creating directory temp
Verifying archive integrity...  100%   MD5 checksums are OK. All good.
Uncompressing release  100%
firmware_updater/
firmware_updater/lib_setup.sh
tar: firmware_updater/lib_setup.sh: time stamp 2024-11-13 02:35:12 is 532298317.067090068 s in the future
firmware_updater/install.sh
tar: firmware_updater/install.sh: time stamp 2024-11-13 02:35:12 is 532298317.066919946 s in the future
firmware_updater/lib_unsetup.sh
tar: firmware_updater/lib_unsetup.sh: time stamp 2024-11-13 02:35:12 is 532298317.066848859 s in the future
firmware_updater/firmware.files
tar: firmware_updater/firmware.files: time stamp 2024-11-13 02:35:12 is 532298317.066779927 s in the future
firmware_updater/os/
firmware_updater/os/centos/
firmware_updater/os/centos/centos_init.sh
tar: firmware_updater/os/centos/centos_init.sh: time stamp 2024-11-13 02:35:12 is 532298317.06666837 s in the future
firmware_updater/os/velo/
tar: firmware_updater/os/centos: time stamp 2024-11-13 02:35:12 is 532298317.066631222 s in the future
firmware_updater/os/velo/driver/
firmware_updater/os/velo/driver/v4.14.106/
firmware_updater/os/velo/driver/v4.14.106/amifldrv_mod.md5sum
tar: firmware_updater/os/velo/driver/v4.14.106/amifldrv_mod.md5sum: time stamp 2024-11-13 02:35:12 is 532298317.066530285 s in the future
firmware_updater/os/velo/driver/v4.14.106/amifldrv_mod.o
tar: firmware_updater/os/velo/driver/v4.14.106/amifldrv_mod.o: time stamp 2024-11-13 02:35:12 is 532298317.066038626 s in the future
firmware_updater/os/velo/driver/v4.14.239/
tar: firmware_updater/os/velo/driver/v4.14.106: time stamp 2024-11-13 02:35:12 is 532298317.066002127 s in the future
firmware_updater/os/velo/driver/v4.14.239/amifldrv_mod.md5sum
tar: firmware_updater/os/velo/driver/v4.14.239/amifldrv_mod.md5sum: time stamp 2024-11-13 02:35:12 is 532298317.065929965 s in the future
firmware_updater/os/velo/driver/v4.14.239/amifldrv_mod.o
tar: firmware_updater/os/velo/driver/v4.14.239/amifldrv_mod.o: time stamp 2024-11-13 02:35:12 is 532298317.064591939 s in the future
firmware_updater/os/velo/driver/v4.14.149/
tar: firmware_updater/os/velo/driver/v4.14.239: time stamp 2024-11-13 02:35:12 is 532298317.06455461 s in the future
firmware_updater/os/velo/driver/v4.14.149/amifldrv_mod.md5sum
tar: firmware_updater/os/velo/driver/v4.14.149/amifldrv_mod.md5sum: time stamp 2024-11-13 02:35:12 is 532298317.064480747 s in the future
firmware_updater/os/velo/driver/v4.14.149/amifldrv_mod.o
tar: firmware_updater/os/velo/driver/v4.14.149/amifldrv_mod.o: time stamp 2024-11-13 02:35:12 is 532298317.063830973 s in the future
firmware_updater/os/velo/velo_init.sh
tar: firmware_updater/os/velo/driver/v4.14.149: time stamp 2024-11-13 02:35:12 is 532298317.063794382 s in the future
tar: firmware_updater/os/velo/driver: time stamp 2024-11-13 02:35:12 is 532298317.063774929 s in the future
tar: firmware_updater/os/velo/velo_init.sh: time stamp 2024-11-13 02:35:12 is 532298317.063718445 s in the future
firmware_updater/os/ubuntu/
tar: firmware_updater/os/velo: time stamp 2024-11-13 02:35:12 is 532298317.063677624 s in the future
firmware_updater/os/ubuntu/ubuntu_init.sh
tar: firmware_updater/os/ubuntu/ubuntu_init.sh: time stamp 2024-11-13 02:35:12 is 532298317.063607936 s in the future
firmware_updater/os/versa/
tar: firmware_updater/os/ubuntu: time stamp 2024-11-13 02:35:12 is 532298317.063573993 s in the future
firmware_updater/os/versa/versa_uninit.sh
tar: firmware_updater/os/versa/versa_uninit.sh: time stamp 2024-11-13 02:35:12 is 532298317.063506364 s in the future
firmware_updater/os/versa/driver/
firmware_updater/os/versa/driver/i2c-ismt.ko
tar: firmware_updater/os/versa/driver/i2c-ismt.ko: time stamp 2024-11-13 02:35:12 is 532298317.063365535 s in the future
firmware_updater/os/versa/versa_init.sh
tar: firmware_updater/os/versa/driver: time stamp 2024-11-13 02:35:12 is 532298317.063330511 s in the future
tar: firmware_updater/os/versa/versa_init.sh: time stamp 2024-11-13 02:35:12 is 532298317.063275397 s in the future
firmware_updater/os/common_func.sh
tar: firmware_updater/os/versa: time stamp 2024-11-13 02:35:12 is 532298317.063241627 s in the future
tar: firmware_updater/os/common_func.sh: time stamp 2024-11-13 02:35:12 is 532298317.063176506 s in the future
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
tar: firmware_updater/os/debian/driver/9.9/amifldrv_mod.o: time stamp 2024-11-13 02:35:12 is 532298316.722806949 s in the future
firmware_updater/os/debian/driver/10.2/
tar: firmware_updater/os/debian/driver/9.9: time stamp 2024-11-13 02:35:12 is 532298316.722697125 s in the future
firmware_updater/os/debian/driver/10.2/amifldrv_mod.o
tar: firmware_updater/os/debian/driver/10.2/amifldrv_mod.o: time stamp 2024-11-13 02:35:12 is 532298316.713037207 s in the future
firmware_updater/os/debian/driver/10.0/
tar: firmware_updater/os/debian/driver/10.2: time stamp 2024-11-13 02:35:12 is 532298316.712947055 s in the future
firmware_updater/os/debian/driver/10.0/amifldrv_mod.o
tar: firmware_updater/os/debian/driver/10.0/amifldrv_mod.o: time stamp 2024-11-13 02:35:12 is 532298316.703967458 s in the future
firmware_updater/os/debian/driver/9.8/
tar: firmware_updater/os/debian/driver/10.0: time stamp 2024-11-13 02:35:12 is 532298316.703885662 s in the future
firmware_updater/os/debian/driver/9.8/amifldrv_mod.o
tar: firmware_updater/os/debian/driver/9.8/amifldrv_mod.o: time stamp 2024-11-13 02:35:12 is 532298316.698833696 s in the future
firmware_updater/os/debian/debian_init.sh
tar: firmware_updater/os/debian/driver/9.8: time stamp 2024-11-13 02:35:12 is 532298316.698785233 s in the future
tar: firmware_updater/os/debian/driver: time stamp 2024-11-13 02:35:12 is 532298316.698764777 s in the future
tar: firmware_updater/os/debian/debian_init.sh: time stamp 2024-11-13 02:35:12 is 532298316.698691643 s in the future
firmware_updater/firmwares/
tar: firmware_updater/os/debian: time stamp 2024-11-13 02:35:12 is 532298316.69865673 s in the future
tar: firmware_updater/os: time stamp 2024-11-13 02:35:12 is 532298316.698636366 s in the future
firmware_updater/firmwares/Linux_DLMC_SFDN007E_20240704_New.tar
tar: firmware_updater/firmwares/Linux_DLMC_SFDN007E_20240704_New.tar: time stamp 2024-11-13 02:35:12 is 532298316.676893161 s in the future
firmware_updater/firmwares/SBR10015_646_1TB_m2_2280_D_DEL_ISP.bin
tar: firmware_updater/firmwares/SBR10015_646_1TB_m2_2280_D_DEL_ISP.bin: time stamp 2024-11-13 02:35:12 is 532298316.667579448 s in the future
firmware_updater/firmwares/vep1400x_cpld_versa_transfr_v18_2023_0424.vme
tar: firmware_updater/firmwares/vep1400x_cpld_versa_transfr_v18_2023_0424.vme: time stamp 2024-11-13 02:35:12 is 532298316.666291604 s in the future
firmware_updater/firmwares/VEP1400-X-BIOS-3.50.0.9-21.bin
tar: firmware_updater/firmwares/VEP1400-X-BIOS-3.50.0.9-21.bin: time stamp 2024-11-13 02:35:12 is 532298316.533947578 s in the future
firmware_updater/firmwares/N1406_App_V40Q_230414.bin
    ===== Cancel the Update Process =====

    Error: Can not find the i2c bus of CPLD

root@dellemc-diag-os:/boot#

Is there a way to update the BIOS and NVRAM without the use of the script? I've tried running the .bin files by themselves but it doesn't seem to work.

EDIT: I poked around the update script and found that you can run updatetool by itself. The command that seems to have worked for me is updatetool --dev=BIOS --update --whole --file=VEP1400-X-BIOS-3.48.0.9-23.bin --config=/etc/dn/diag/default_update_device.xml. After reboot I can boot into BIOS version 3.48.0.9-23. However when I boot into DiagOS, CPLD is still missing.

 

[nmpu]

After reboot I can boot into BIOS version 3.48.0.9-23. However when I boot into DiagOS, CPLD is still missing.

I told you to run from /boot. I just checked the documentation and it says /root. For me, the script loads without error either way. Curiously, the BIOS on my 640 (not N) is 3.50.0.9-21. I see 3.48.0.9-23 on my 680. Both were updated from the same script.

You're getting closer. When you were experimenting with the small internal pushbuttons, did you hold the button closest to the power jack until the device shuts down?

 

[oneplane]

This:

smbusOneRead failed to setup the address at offset 0, error: SMB rcvd interrupt
Failed to get board infomation
smbusOneRead failed to setup the address at offset 14, error: SMB rcvd interrupt
Error! Failed to read CPLD register for BIOS SPI flash select.
DxE POST

Is the UEFI driver (in the DxE) saying it can't read the board ROM, because the CPLD isn't helping. Usually this means the CPLD has the wrong bitstream or the VEP1400 software is being executed on a non-VEP1400 board.

 

[frantathefranta]

When you were experimenting with the small internal pushbuttons, did you hold the button closest to the power jack until the device shuts down?

I don't think I've held it, I only ever press it and it reboots and seems to try to boot "the other" slot. I gathered some POST logs from yesterday which I'll post later today when I get back to my workstation. The first boot after the BIOS upgrade looked very promising but now I have to wait for the POST to fail 3 times before it "selects the backup BIOS". I think it all comes down to the CPLD being corrupted/broken in some way and until that's fixed I'm not sure if it's gonna work properly.

As to why the update script fails for me, it's because it yet again cannot detect whether it's a VEP1400 or VEP1400-X CPLD and it has no in-script recovery mechanism to continue. It's still possible to execute the firmware upgrade commands individually like I've done.

I bought the box from this listing (bundled with a 610 just like this one, which I haven't touched yet).

 

[oneplane]

We can recover the CPLD via the header on the board, I think I have a VEP1400-X dump from mine and a VEP1400 dump from someone else where, raw bitstreams can be read/written just fine. They didn't disable debugging either, so you can actually access it using the official software, out-of-band.

Biggest issue is when the CPLD is written with bad data, it will not be in-band recoverable because the I/O interface won't be available anymore.

 

[frantathefranta]

We can recover the CPLD via the header on the board, I think I have a VEP1400-X dump from mine and a VEP1400 dump from someone else where, raw bitstreams can be read/written just fine. They didn't disable debugging either, so you can actually access it using the official software, out-of-band.

Biggest issue is when the CPLD is written with bad data, it will not be in-band recoverable because the I/O interface won't be available anymore.

I'd be interested in trying that. Do I need the CH341A programmer or is that for something else?

 

[oneplane]

I'd be interested in trying that. Do I need the CH341A programmer or is that for something else?

Let's verify a few things first; you have this one: https://infohub.delltechnologies.co...l-emc-sd-wan-edge-640-standard-configuration/ correct? I know the N-suffix is probably a version that doesn't have some wireless protocol or is a country-specific edition but the hardware should be the same otherwise.

 

[nmpu]

I bought the box from this listing (bundled with a 610 just like this one, which I haven't touched yet).

OK, you've learned a lot, but I'd cut your losses. Your 640N shows BIOS errors on boot. The item was sold as 'used' which implies 'fully operational and functions as intended'. There are no updates available for your bundled 610. I just got a working 640 (with Wi-Fi) for $39. I've got 2 (as-is) 680s on the way that cost me $50 each. I'd contact your seller. You'll likely get a partial refund. If you force a return (not as described), there's a good chance they'll let you keep the stuff. These recycler outfits likely got the stuff for free. They say fully tested, blah, blah, but we know it's far more complicated than watching for power or link LEDs.

 

[frantathefranta]

Let's verify a few things first; you have this one: https://infohub.delltechnologies.co...l-emc-sd-wan-edge-640-standard-configuration/ correct? I know the N-suffix is probably a version that doesn't have some wireless protocol or is a country-specific edition but the hardware should be the same otherwise.

Yep, should be a 640N.

TLV Name             Code Len Value
-------------------- ---- --- -----
Product Name         0x21   9 EDGE640VN
Part Number          0x22   6 07071K
Serial Number        0x23  20 TW07071KDNT0025U0588
Base MAC Address     0x24   6 E8:B5:D0:71:DA:32
Manufacture Date     0x25  19 05/30/2022 14:59:45
Device Version       0x26   1 1
Label Revision       0x27   3 A01
Platform Name        0x28  22 x86_64-dellemc_edge640
MAC Addresses        0x2A   2 64
Manufacturer         0x2B   5 DNT00
Country Code         0x2C   2 TW
Vendor Name          0x2D   8 Dell EMC
Service Tag          0x2F   7 FYDVV43
Vendor Extension     0xFD  21  0x00 0x00 0x02 0xA2 0x20 0x8D 0xBC 0xDC 0x12 0xE6 0x35 0x4D 0x14 0x9A 0xE8 0xD0 0x7D 0x3E 0x01 0xA4 0x66
Diag Version         0x2E  12 3.43.3.81-27
CRC-32               0xFE   4 0xF7772A42

OK, you've learned a lot, but I'd cut your losses. Your 640N shows BIOS errors on boot. The item was sold as 'used' which implies 'fully operational and functions as intended'. There are no updates available for your bundled 610. I just got a working 640 (with Wi-Fi) for $39. I've got 2 (as-is) 680s on the way that cost me $50 each. I'd contact your seller. You'll likely get a partial refund. If you force a return (not as described), there's a good chance they'll let you keep the stuff. These recycler outfits likely got the stuff for free. They say fully tested, blah, blah, but we know it's far more complicated than watching for power or link LEDs.

May I know where you've gotten yours? I'm still interested in a working 640. I'll reach out to the seller and we'll see what's up.

 

[nmpu]

May I know where you've gotten yours? I'm still interested in a working 640. I'll reach out to the seller and we'll see what's up.

The $30.00 + $8.59 shipping was a 3-day auction, so not like I scored a quick buy-it-now. The 680s are currently priced MUCH higher on eBay. After I test the 2 units, I will decide whether to buy the rest even cheaper or share the link on the Great Deals forum. I don't need this many devices, but I'm in a position where I have experience and some spare parts (SATA/NVMe drives, adapter PCBs, power supplies, etc). I'll probably purge my 2 640s and keep all 680s.

You seem to be OK with tinkering. I would not abandon your 640N if you can get the cost way down. I just hate to see people guessing. All the public troubleshooting tends to make the devices appear problematic. I think everyone with a 620/640/680 has eventually got them updated and configured. After that, they just complain about the fan noise.

I recently fried a perfectly good 640 by accidently plugging a 48V POE adapter. What a waste. The fix is probably simple. I suspect it's a power-management IC. Problem is, everything is so tiny and the IC requires a custom OTP profile. I have to let it go. I pulled the SATA SSD, the 16GB SODIMM, and I'll have some spare fans. The plastic case was in good shape. I had already removed the Wi-Fi module and antennas.

 

[frantathefranta]

I did get a replacement 640 sent by the seller, we’ll see if that one is better. I feel like the one I have now is still salvageable so I’m going to keep trying, if I can figure out the CPLD. So far it’s been my late nights project so I don’t feel like I’m wasting too much time on it.

 

[oneplane]

Yep, should be a 640N.

TLV Name             Code Len Value
-------------------- ---- --- -----
Product Name         0x21   9 EDGE640VN
Part Number          0x22   6 07071K
Serial Number        0x23  20 TW07071KDNT0025U0588
Base MAC Address     0x24   6 E8:B5:D0:71:DA:32
Manufacture Date     0x25  19 05/30/2022 14:59:45
Device Version       0x26   1 1
Label Revision       0x27   3 A01
Platform Name        0x28  22 x86_64-dellemc_edge640
MAC Addresses        0x2A   2 64
Manufacturer         0x2B   5 DNT00
Country Code         0x2C   2 TW
Vendor Name          0x2D   8 Dell EMC
Service Tag          0x2F   7 FYDVV43
Vendor Extension     0xFD  21  0x00 0x00 0x02 0xA2 0x20 0x8D 0xBC 0xDC 0x12 0xE6 0x35 0x4D 0x14 0x9A 0xE8 0xD0 0x7D 0x3E 0x01 0xA4 0x66
Diag Version         0x2E  12 3.43.3.81-27
CRC-32               0xFE   4 0xF7772A42

May I know where you've gotten yours? I'm still interested in a working 640. I'll reach out to the seller and we'll see what's up.

If that is realtime/direct data it means the system ID ROM is still fine and the TLV readout works (and as a result I2C/SPI for that works too).

The weird thing here is that there are links on Dell's site like Dell EMC Diagnostics OS V3.43.3.81-25 for EDGE 600 Switch. | Driver Details | Dell UK where it will mention VEP1400 non-X images for EDGE600 series, but the platform name isn't dellemc_edge640.

Either way, since we have a plaintext copy of the TLV data from the ROM, the worst case recovery is just re-entering that data over SPI.

The EDA Tool and Diagnostic tools can be run with skip for things that don't work out, this should be enough to get the firmwares from the controller, UEFI, CPLD etc. and if only the CPLD failed that makes recovery a bit easier. I'll check if I have a non-X model lying around here to see if the CPLD falls back to PCI when the side channel is down or bitstream is missing; if so, this should be fixable from diag-OS. Problem is that you specified a specific default XML file while it should only select the file that has the same TLV as the ROM as the updater is a bit dumb and just copies the values from the XML and if it selects the wrong XML it also puts in the wrong firmware and config.

 

[nmpu]

@oneplane I suppose we should ask the community if anyone else has a 640N? I think I remember photos of a 620N.

I do wonder why there are 2 different BIOS versions displayed for the same update package. @frantathefranta currently has 3.48.0.9-23 which is what I see on my 680 (Wi-Fi). However, my 640 (Wi-Fi) has 3.50.0.9-21. I wouldn't think the hardware differences were enough to warrant a separate BIOS build. It seems like you'd use some conditional code instead. I'm pretty sure the N suffix came later-- at least on eBay.

I would like to know where the hardware config is stored. I'd rather omit the Wi-Fi module from consideration than ignore a failed POST. I typically remove the Wi-Fi for power savings or replace with an NVMe drive.

I just updated another 680 (Wi-Fi) and the firmware is 3.50.0.9-21. This makes me think the BIOS difference is not based on the model or hardware revision, but probably the sales channel. I have 2 identical models with ship dates 2 months apart. Both were updated with the 2.6 package. The other shows 3.48.0.9-23.

 

[nmpu]

Has anyone got QAT working in Debian (Proxmox)? It seems like there's lots of hype but nobody can figure out how to use it.