I have an industrial robot arm that has VxWorks running in the controller. I am very new to VxWorks. When I tried to use ftp, there was a password issue. After going through the vxworks boot procedure, I can no longer get the system to boot. I get the following screen through HyperTerminal.
VxWorks System Boot
Copyright 1984-2002 Wind River Systems, Inc.
CPU: PC PENTIUM
Version: VxWorks5.5.1
BSP version: 1.2/2
Creation date: Nov 3 2006, 09:55:58
Press 's' to stop auto-boot...
auto-booting...
boot device : ata
unit number : 0
processor number : 0
host name : NITT
file name : /ata0/vxWorks
inet on ethernet (e) : 192.168.0.253:1947
host inet (h) : 192.168.0.255
user (u) : me
ftp password (pw) : pw
flags (f) : 0x00
other (o) : fei
Attaching to USB disk device...
USBLink, USB Stack Driver, ver 2.02 (build 31/01/2006), staubli rev 1.10
Copyright SoftConnex LLC, 1999. All rights reserved...
UHCI USB Controller initialized ...
Can't load boot file!!
I look at the terse help menue...
[VxWorks Boot]: ?
? - print this list
# - boot (load and go)
p - print boot params
c - change boot params
l - load boot file
g adrs - go to adrs
d adrs[,n] - display memory
m adrs - modify memory
f adrs, nbytes, value - fill memory
t adrs, adrs, nbytes - copy memory
e - print fatal exception
v - print boot logo with version
n netif - print network interface device address
$dev(0,procnum)host:/file h=# e=# b=# g=# u=usr [pw=passwd] f=#
tn=targetname s=script o=other
boot device: ata=ctrl,drive file name: /ata0/vxWorks
boot device: usbstbl file name: /usbdsk0/vxWorks
Boot flags:
0x02 - load local system symbols
0x04 - don't autoboot
0x08 - quick autoboot (no countdown)
0x20 - disable login security
0x40 - use bootp to get boot parameters
0x80 - use tftp to get boot image
0x100 - use proxy arp
available boot devices:Enhanced Network Devices
fei0 fei1 ata usbstbl
[VxWorks Boot]:
The system did previously boot without a PC.
Does anyone see any errors in the parameters?
You have the system configured to load from the ata device. We can see from this line:
available boot devices:Enhanced Network Devices
fei0 fei1 ata usbstbl
that the ata device does exist. So, the most likely explanation is that the file /ata/vxworks no longer exists. Perhaps it has been deleted, or maybe corrupted, or the disk has been formatted. You can check what is on disk using the ls command:
ls /ata
You may be able to recover using another boot method, eg configure to download the boot image via the network or, assuming that usbstb1 is some form of removable storage, by copying a vxworks image onto the system that way.
Using a USB device, you can either modify the boot config to temporarily load the vxworks from the USB (you will need to modify boot device and file name settings), or use the bootloader shell commands to copy the boot file to the target.
Copy file from USB
Using a PC, copy the vxworks image to the USB device - it doesnt matter where, as long as you know where.
Insert the USB into your target.
using the shell commands, copy the file eg
cp /usbdsk0/vxWorks /ata0/vxWorks
Related
TL;DR: After a restart of Big Sur, a System Report sees the USB modem (S/N 12345678), but /dev/cu.usbmodem123456781 does not exist until the modem is unplugged and plugged back in.
I'm using a USB modem (macOS) with a chipset made by Conexant.
With Mojave, my application worked fine -- always found the USB modem using this code:
ORSSerialPortManager *serialPortManager = [ORSSerialPortManager sharedSerialPortManager];
NSArray *availablePorts = serialPortManager.availablePorts;
// usbmodem123456781,
// "Bluetooth-Incoming-Port",
// URT1
NSString *modemPath = nil;
for ( ORSSerialPort *aPort in availablePorts ) {
NSLog(#"aPort.description %#",aPort.description);
if ( [aPort.description hasPrefix:#"usbmodem"] ) {
// the modem has been found, the path is:
// "/dev/cu.usbmodem123456781"
}
}
However, with Big Sur (I skipped Catalina), the modem is not detected after a restart. Immediately after a restart, availablePorts is just this (usbmodem123456781 is missing):
// "Bluetooth-Incoming-Port",
// URT1
But, if I plug the modem in after the restart
(by unplugging and plugging back in), the modem is found.
Thus, macOS Big Sur only recognizes the modem if it is (re)connected after a restart.
ls -lt shows this after a restart and after a power cycle of the modem:
crw-rw-rw- 1 root wheel 9, 5 Mar 16 11:18 cu.usbmodem123456781
crw-rw-rw- 1 root wheel 9, 4 Mar 16 11:18 tty.usbmodem123456781
Neither of those lines are present after a restart until the modem is
plugged in again.
What can I do programatically that will activate and detect the modem even after a restart?
Edit: the macOS System Report sees the USB device, before and after I unplug/replug:
We connected L89 GNSS module to processor via UART. I may running gpsmon and gpspipe commands on board but but not getting NMEA logs. But when we were connected L89 to processor via USB, that time I am getting NMEA logs on gpsmon and gpspipe, what is issue with UART?
I edit /etc/default/gpsd file.
# Default settings for gpsd.
# Please do not edit this file directly - use `dpkg-reconfigure gpsd' to
# change the options.
START_DAEMON="true" command to continue
GPSD_OPTIONS=""
DEVICES="/dev/ttyS1"
USBAUTO="false"
GPSD_SOCKET="/var/run/gpsd.sock"
but I am not getting NMEA data using gpsd...
Just start using XenServer. Doing some experiment for my company. Installed XenServer 7.4 on a Box and created a Centos 6.9 VMU. Using XenCenter.
Got to the point when I can run the virtual operating system but when I try to use the "Advanced Micro Devices, Inc. [AMD/ATI] Tonga XT GL [FirePro S7150]" graphic card with the command:
xe vgpu-create vm-uuid=xxx-xxx-xxx-xxx gpu-group-uuid=xxx-xxx-xxx-xxx
I receive the following error message:
The use of this feature is restricted.
I have also tried to install the graphic interface (Xen-Center) using a licensed Xen-Server to enable the AMD card using the Tools->Install Update: downloaded and selected the mxgpu-1.0.5.amd.iso to enable the Graphic card but I cannot complete the process as I receive the error message:
The attempt to create a VDI failed
I am running out of option. The CentOS is running but I cannot use the machine AMD graphic card. Can you help?
Could you try running the VM with the virtual disk stored on the same Local Storage repository located on that card's host, and removed from any pools. This is the default configuration, but I'd thought I'd mention these tips in case you have this box somehow mixed in a heterogenous pool. If the machine is part of a pool, make sure that you are not selecting the video adapter to passthrough to the VM of another host's adapter.
I'm trying to use the WinUsb.sys driver that comes with Windows (including Windows 10 IoT of Raspberry Pi 2). Using devcon.exe I can see that the USB I'm trying to use is connected (it is named USB\VID_1234&PID_ABCD\5&3753427A&0&4), but I don't know how to force it to use the WinUsb.sys driver.
I found some instructions on microsoft.com but that seems to be for a standard Windows installation where you have Device Manager available (which I don't have on IoT). The INF file example on this page also refers to a CAT-file, which I assume this is some sort of driver signature, and I don't know how to generate this (or if I even need to). There's also a reference to Windows NT (Signature = "$Windows NT$") and I don't know if that needs to be changed for IoT or not (or if anything else needs to be changed for IoT for that matter).
So, using devcon.exe and some sort of INF file, how can I get Windows IoT to use WinUsb.sys as a driver for the USB device I'm attaching?
After a lot of trial and error I finally got it working. Here's a complete INF-file for future reference:
; WinUSB installation file for USB device
[Version]
Signature = "$Windows NT$"
Class = USBDevice
ClassGUID = {88BAE032-5A81-49f0-BC3D-A4FF138216D6}
Provider = %ManufacturerName%
CatalogFile = WinUSBInstallation.cat
DriverVer=09/04/2012,13.54.20.543
; ========== Manufacturer/Models sections ===========
[Manufacturer]
%ManufacturerName%=Standard,NTarm
[Standard.NTarm]
%DeviceName% =USB_Install, USB\VID_1234&PID_ABCD
; ========== Class definition ===========
[ClassInstall32]
AddReg = ClassInstall_AddReg
[ClassInstall_AddReg]
HKR,,,,%ClassName%
HKR,,NoInstallClass,,1
HKR,,IconPath,%REG_MULTI_SZ%,"%systemroot%\system32\setupapi.dll,-20"
HKR,,LowerLogoVersion,,5.2
; =================== Installation ===================
[USB_Install]
Include = winusb.inf
Needs = WINUSB.NT
[USB_Install.Services]
Include =winusb.inf
Needs = WINUSB.NT.Services
[USB_Install.HW]
AddReg=Dev_AddReg
[Dev_AddReg]
HKR,,DeviceInterfaceGUIDs,0x10000,"{ec55ee47-5758-4378-926b-68ed0aec8170}"
; =================== Strings ===================
[Strings]
ManufacturerName="The name of the company producing your device"
ClassName="Universal Serial Bus devices"
DeviceName="The name of your device"
REG_MULTI_SZ = 0x00010000
Replace the Vendor ID (VID) and Product ID (PID) in [Standard.NTarm] with the corresponding VID and PID of the USB you're adding.
Finally replace the ManufacturerName and DeviceName near the bottom with the correct info for your device.
Put this file somewhere on the Raspberry Pi 2, using either SMB or FTP.
SSH or PowerShell to the Raspberry Pi 2 and go to the folder where you put the INF file.
Run the following command: devcon dp_add .\<name of your INF file>
You should see the following result: Driver package 'oem0.inf' added.
Finally restart the RP2 (shutdown -r -t 0 from SSH/PowerShell).
When the RP2 gets back up your device should be listed under "Connected Devices" on the default startup app, and you should now be able to use functionality from Windows.Devices.Usb to communicate with the USB device.
Summary
My aim is to control the GPIO pins in Peppermint 4 Linux (Kernel version 3.8.0) on an Intel motherboard (NM70 chipset with C1037U processor).
I'm debugging issues I'm having using the sysfs interface and am trying to understand the conditions where /sys/kernel/debug/gpio would be empty?
When attempting to export pins 0 to 255 by
echo XX > /sys/class/gpio/export
for XX from 0 to 255, I get the following error message
echo: write error: No such device
Under what conditions would /sys/kernel/debug/gpio be empty?
Background
Motherboard: Intel with NM70 chipset
Processor: C1037U processor
OS: Peppermint 4 Linux
Kernel version: 3.8.0
GPIO interface: sysfs
I'm attempting to use the sysfs interface, which allows GPIO pins to be accessed from userspace through the filesystem.
I’ve successfully followed the "Alternate Build Method: The Old-Fashioned Debian Way" section of https://help.ubuntu.com/community/Kernel/Compile to recompile the kernel in order to expose GPIO access in user space and to turn on debug mode for GPIO:
Once the new kernel was compiled, I was able to see the GPIO folder in /sys/class/gpio for the first time. Then, in theory, it should be a case of being able to turn GPIO ports ON/OFF by writing to the filesystem. This approach is outlined at http://falsinsoft.blogspot.co.uk/2012/11/access-gpio-from-linux-user-space.html.
When attempting to export pins 0 to 255 by
echo XX > /sys/class/gpio/export
for XX from 0 to 255, I get the following error message
echo: write error: No such device
When attempting to export pins outside the range 0 to 255 by
echo XX > /sys/class/gpio/export
I get the following error message
echo: write error: Invalid argument
The tutorial suggests this could be because the GPIO ports are reserved for another program and that, if so, the debug file (/sys/kernel/debug/gpio) would be able to show where they are reserved.
However, /sys/kernel/debug/gpio is empty.
I can see and control the GPIO pins in the BIOS (change pins to be input or output HIGH/LOW).
Related questions
writing to /sys/class/gpio/export failing
Enable pullup GPIO
/sys/kernel/debug/gpio will be empty if there no GPIO device registered (warning: when I say GPIO device, I don't mean the piece of hardware, but rather the kernel representation of it).
So, these GPIO devices are registered at runtime by the kernel and associated to a specific GPIO device driver.
In turn, the GPIO device driver is selected and associated to a given device, because it is the one declaring compatibility with said GPIO device.
E.g., the kernel would match on PCI vendor and product ID, and probe a GPIO driver that claims support for that PCI vendor/product. When the GPIO driver is probed, it typically registers the GPIO device instance.
Finally, that registered GPIO device is what provides GPIOs shown in /sys/kernel/debug/gpio.
The above is part of the so-called "Device Driver model" in Linux. Although it's a bit outdated, you can read [1].
Now, let's see what GPIO driver you need to select for your NM70 chipset. Wikipedia says that the chipset codename is "Panther Point-M" [2]. With some luck, the lpc_ich driver could support it. You would have to build your kernel with CONFIG_LPC_ICH=y.
Alternatively, if your GPIOs are provided by a PCI device, you could use lspci to get the IDs, and then grep in the kernel sources for those IDs.
[1] http://www.oreilly.com/openbook/linuxdrive3/book/ch14.pdf
[2] https://en.wikipedia.org/wiki/List_of_Intel_chipsets