Vmware Download 64-bit Windows 7

0 views

Skip to first unread message

Argelia Long

unread,

Aug 3, 2024, 6:12:34 PM8/3/24

to mafectimyf

I am recently responsible for maintaining a codebase with a coldfire V2 target (MCF52277) that includes MQX RTOS 3.0.1. This codebase will compile under codewarrior 7.1.1. I would like to use the existing tool chain (codewarrior 7.1.1 and PEmicro Coldfire Multilink debugger, USB-ML-CFE) to compile, debug, and build the firmware. I have a Windows 7 64-bit machine and have been unsuccessful at using the PEmicro debugger with Codewarrior. I tried the following two methods and both failed. Do you have any suggestions?

I followed the freescale recommended procedure to install classic codewarrior 7.1.1 on a 64 bit machine (see instructions here _dev_tools/doc/app.../AN3936.pdf ). I installed Windows Virtual PC and Windows XP mode. I installed codewarrior 7.1 in the windows XP virtual machine. This allowed me to compile my code. I plug in the pemicro debugger to the USB port and my Windows 7 device found it (latest pemicro drivers were installed). However, when I try to attach in XP mode, it will not attach the USB device. I most cases when I try to attached on several USB ports, it will not attach to the virtual machine and so I can not run the debugger. In a few attempts, the virtual machine did attach, but the lights on the USB multilink turn off and a message appears in XP Mode that the USB device has become non-functional. I have tried multiple PE debuggers and encountered the same problem.

I installed codewarrior 7.1.1 directly on my Windows 7 64 bit machine. There were a view warnings/errors during installation, but I ignored these and codewarrior seemed to install ok. I was able to compile the code. The USB Multilink 2.0 device shows up in the windows devices list. However, when I try to connect or run the debugger, Codewarrior produces the following error "ColdFire PE Protocol Adapter: No USB connection found" message.

I found out later that my answer above was only partially correct. I was able to use the flash programmer to download data but not step through the debugger. I now have the debugger working completely. See thread below for final answer

I was able to get Method #1 in original description working using Windows XP Mode, although it is flakey. I am not sure what fixed the problem, but I installed the latest driver in the PE USB Multilink device and I installed the latest PE driver both on the real machine AND the virtual machine. Finally, I made the observation that when attaching the USB device for the first time, the debugger turns off. If you then remove the USB connector from the PC and plug it back in, it will be attached to the virtual PC. Thanks for your help,.

But remember the licensing is only for "non commercial use", and "I am recently responsible for maintaining a codebase..." sounds pretty commercial to me. Responsibility should come with a budget for tools, and if you can't keep up to date (with the latest development environment) then you have to spend money to keep old machines and operating systems alive, or you have to run then as VMS to work around the "history gap".

The PE Micro USB Coldfire Multilink seldom works the first time I try. Various combinations of unplugging the USB port, waiting for the lights on the Multilink to come up, then waiting for the device to pop up in VMWARE "VM / Removable Devices", and then waiting for Windows to see it. It then works about 50% of the time. Connecting/Disconnecting in the VMWare Menu and unplugging it a few times usually gets it working. Except for the times every other week when VMWare refuses to see ANY devices, and that requires VMWare to be restarted. The same drama is needed to get the USB-to-CAN converter working. It is a pain, but better than not having it work at all.

Windows 11 requires TPM 2.0. Running Windows 11 as a virtual machine requires a virtual Trusted Platform Module to be present. For more details on Windows 11 requirements see, -us/windows/whats-new/windows-11-requirements .

Virtual TPM devices require vSphere to be configured with a Key Provider. This is a prerequisite requirement before you can create a new VM with a vTPM device or add a vTPM device to an existing VM. In vSphere 8 and vSphere 7 this can be a Native Key Provider or an external third party key provider. (Native Key Provider requires vSphere 7 U2 or later).

See the documentation links below to configure your respective version of vSphere with an appropriate key provider. The procedure for configuring vSphere to support Windows 11, will depend on which version of vSphere you are running. Please take care to follow the procedure for your version of vSphere.

Installing Windows 11 in a virtual machine on vSphere 8 is almost identical to installing previous versions of Windows. The change is that Windows 11 requires a virtual TPM device to be present in the virtual machine.

When creating a new virtual machine, using the vSphere Client, select virtual machine compatibility with ESXi 8.0 and later (hardware version 20) and choose Microsoft Windows 11 (64-bit) as the Guest OS Version.

Note: The recommended choice for virtual storage controller is VMware Paravirtual SCSI (PVSCSI). Refer to add the PVSCSI driver to Windows ISO or provide the driver to Windows during installation by following process mentioned in the section "To install PVSCSI drivers through CD/DVD drive (Recommended)" of KB

When creating a new virtual machine, using the vSphere Client, select a minimum of virtual machine compatibility with ESXi 6.7 U2 and later (hardware version 15) and choose Microsoft Windows 10 (64-bit) as the Guest OS Version. vSphere 6.7 and vSphere 7 do not currently present Microsoft Windows 11 as a specific Guest OS Version. vSphere 8 and hardware version 20 presents Microsoft Windows 11 (64-bit) as a selectable Guest OS Version.

A Trusted Platform Module device is not a default device and must be added manually during the new VM creation wizard. On the Customize Hardware page, click Add New Device, and select Trusted Platform Module from the list of devices.

Lastly, navigate to the VM Options tab of the Hardware Customization page. Expand Encryption and set both Encrypted vMotion and Encrypted FT settings to Required. Normally this would not be needed and is a known issue. See KB Article 85974 for more details. When using vSphere 8 and hardware version 20, these settings are automatically selected for Windows 11 virtual machines.

When you clone a virtual machine, that contains a vTPM device, the vTPM device and stored secrets are also cloned. This is desired if Windows features utilizing vTPM, such as Windows BitLocker or Windows Hello, are activated but best practice is to ensure that each Windows 11 virtual machine contains a unique vTPM device.

If you remove or replace the vTPM device on a Windows 11 VM using features like Windows BitLocker or Windows Hello, these features will cease functionality and you may lose access to the Windows operating system or data if you are without the appropriate recovery options.

vSphere 8 introduces the TPM Provision Policy. vTPM devices can be automatically replaced during clone or deployment operations. This allows best practices that each VM contain a unique TPM device be followed and improves vSphere support for Windows 11 deployment at scale. vSphere 8.0 also includes the vpxd.clone.tpmProvisionPolicy advanced setting to make the default clone behaviour for vTPMs to be replaced.

When you deploy a virtual machine from a VM template containing a vTPM device, the same caveats apply as when cloning a virtual machine with a vTPM device. The vTPM of the deployed VM is an identical copy of that of the template. In vSphere 8, when deploying Windows 11 VMs from template, the TPM Provision Policy is applied and you can either copy or replace the vTPM device during template deployment. In vSphere 7, you can customize the virtual machine hardware and remove and re-add the vTPM device manually during the template deployment wizard.

Virtual machines with a vTPM device can be stored in the VM Template (VMTX) format. Virtual machines with a vTPM device can be stored in a Content Library, but they must be stored as the VM Template (VMTX) format.

Important: VM Templates with vTPM devices can be deployed from a Content Library. In vSphere 8, currently the default TPM provision policy (copy) is applied and cannot be changed during deployment from a Content Library. The vSphere Client will display a message:

Virtual machines with a vTPM device do not support the OVF/OVA template format directly. It is not supported to export a virtual machine with a vTPM device to an OVF/OVA file using the vSphere Client. The vTPM device must be first removed before you can export the VM as an OVF/OVA template.

Similarly, when importing an OVF/OVA into vSphere using the vSphere Client, a vTPM device must be manually added to the VM after import. The vSphere Client displays a warning message when deploying an OVF template or importing an OVF to a Content Library stating that the imported VM will not contain a vTPM device, even if the OVF contains a vTPM placeholder. See Using OVF Tool with vTPM Virtual Machines below.

Important: The vSphere Client and Content Library service do not currently recognise vTPM placeholder attributes. When importing an OVF/OVA template that does contain vTPM placeholder attributes this section is ignored and the imported virtual machine or template will not have a vTPM device associated with it. You must manually add a vTPM device to the imported machine. VMware is working to improve this workflow in a future release. See Using OVF Tool with vTPM Virtual Machines below.