I have a KMDF driver. This driver can read ACPI _DSM methods by sending IOCTL to its local IO target(ACPI driver) by calling WdfDeviceGetIoTarget(Device).
Below is the device stack:
Device stack
But now, I created lower filter driver(UMDF) to my KMDF driver and device stack is below:
New device stack
So, now I need to create Remote IO target to ACPI driver to send IOCTL. I know that we can call local IO target in MydriverUMDF.dll but I need to send IOCTL from MydriverKMDF.sys only.
Does anyone has any idea please help me to do this?.
Thanks in advance!
WdfIoTargetOpen() requires some info abt ACPi driver like device obj, file obj, device interface.
Related
For all of these scenarios, I am able to upload the firmware and monitor via serial usb. But after creating my first firmware, for all new firmware, I can't upload Lua scripts using the nodemcu-tool without getting the following:
Error Message
F:\Development\NodeMCU\helloworld>nodemcu-tool -p COM3 upload init.lua
[NodeMCU-Tool]~ Unable to establish connection
[NodeMCU-Tool]~ Invalid node.chipid() Response: 6935962
Observations
Can reset the board using nodemcu-tool. Leads me to assume the baud rate is fine.
Can see the file system being created from PuTTy after loading any of the firmware. Leads me to assume the firmware is OK.
Have tried multiple dev boards, same results
Found the source of the error message device-info.js. either line 45 or 49
I have no idea what "Response: 6935962" means. Is that my chip id or an error code?
A new commit was made to the firmware source during the last couple of days. No idea if this is relevant.
Was hoping to get this resolved before I go down the Docker rabbit hole. Lazy. I know.
9/6/2019 - created first firmware to start development
Built a firmware using https://nodemcu-build.com/ with these modules (cron, file, gpio, i2c, mdns, mqtt, net, node, sjson, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
No issues with this firmware. I've been able to upload lua scripts and test them successfully. Even now, I can revert back to this firmware and use it without issues. I've even redownloaded this firmware from the original link, and it works fine.
9/7/2019 - created a new firmware to use adc and other goodies
Built a firmware using https://nodemcu-build.com/ with these modules (adc, cron, file, gpio, i2c, mdns, mqtt, net, node, rtctime, sjson, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
Having the problem described above.
9/8/2019 - built firmware with minimal modules
Built a firmware using https://nodemcu-build.com/ with these modules (file, gpio, net, node, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
Having the problem described above.
Platform & Tools
Windows 10
Development board: HiLetgo ESP8266 NodeMCU LUA CP2102 ESP-12E Internet WiFi Development Board Open Source Serial Wireless Module
Firmware builder: https://nodemcu-build.com/
Serial Monitor: PuTTy 0.72
Firmware Loader: NodeMCUPyFlasher 4.0
Lua script loader: nodemcu-tool 3.0.2
fetchDeviceInfo() first calls node.info() at https://github.com/AndiDittrich/NodeMCU-Tool/blob/master/lib/connector/device-info.js#L9. Then it does an if-else to figure out whether it's running on ESP8266 or ESP32.
With the recent upgrade to SDK 3.0 node.info() was changed in PR #2830. See documentation at https://nodemcu.readthedocs.io/en/latest/modules/node/#nodeinfo. It now returns values the script doesn't consider to be coming from ESP8266. The script then calls node.chipId() in the else branch. So, it's getting a chip id from ESP8266 but it is expecting one from ESP32. Hence, the exception.
I have no idea what "Response: 6935962" means. Is that my chip id or an error code?
It's your chip id.
To cut a long story short: NodeMCU-Tool needs to be adjusted as laid out above to work with the current NodeMCU version.
I cached the same issue from the recent cloud build(https://nodemcu-build.com/). It works when i switch back to the old ones. It looks like a problem of the build system or recent source code. You can switch to other build method and try use the older code.
I am trying to follow directions from the book Exploring Beaglebone. I have also viewed this video which is wrong OSes. I have also read some posts (one, two).
Observed anomalies:
Network Preferences shows a warning of a self-assigned IP address and inability to support internet sharing:
macOS Network Preferences
Debian does not have a 'udhcpc' command but the following was executed:
Screen output
Has anyone been able to do internet over USB on macOS 10.13.2 and Debian 9 IoT?
tnx,
Jon
So a quick intro to what options you have:
Manually enable routing + NAT (No idea how to do that on OSX)
Configure the board system to use DHCP client functionality instead to talk to a shared connection from e.g. OSX.
Permanently disable the script (should be in /opt somewhere) that assigns the current network settings and enables DHCP serving. Might also just be a part of a larger script.
Enable DHCP client (e.g. in /etc/network/interfaces or by using Connman or Network-manager)
The default Debian image should also expose a serial console over USB. You can use this to gain access to and configure the system even when your network connection doesn't work. Of course, the debug-UART should work as well, by using a USB-serial converter.
Another note: the DHCP client on Debian for manual execution is usually dhclient. The interface on the Beaglebone side will be named usb0 or usb1 (as newer images use two types for increased compatibility e.g. with OSX).
A good place to ask questions is usually the Beagleboard Google group
I need to detect a file being created on a NAS drive. The system that needs to be notified is running Windows. I first tried Watch 4 Folder 2.5 but it did not work. The author reports it does not support network drives.
So I looked for ways to develop my own utility. I found the ATFileNotification Component for Delphi.
It can detect changes if the Windows machine that is running the notify utility creates or deletes the file on the network share. However, if the file is created by any other machine on the network, the utility does not notify.
The ATFileNotification component encapsulates the Win32 FindFirstChangeNotification function. Is the inability to detect changes on a remote drive not caused by the system where it is running a fundamental shortcoming of FindFirstChangeNotification, or is there some type of parameter I need to set or other workaround?
If FindFirstChangeNotification is unable to perform this task, is there any method to detect remote files other than polling the remote directory on a timer?
Guys i am using a code segment to detect red color with camera and at the same time taking data with sensonrs in multithread. After a while I am getting "No Such Device" error and camera and all usb devices such as mouse and keyboard are frozing. Is there any idea what is the source of this error?
I had a similar problem, caused by xhci usb (high speed usb) driver disabling my internal usb hub. It occurred each time I've run an OpenCV based application and crash it / kill it. This caused timeout of xci usb driver, which could be seen in dmesg.
The only solution I found was to build a custom kernel for my Kubuntu Linux, which included high-speed usb driver as a module, instead of having it compiled into the kernel.
I've used this wiki to set-up kernel building environment, and changed xhciusb module from *(compiled into kernel) to M(module plugged into kernel at runtime).
If we want to access(read/write) SATA drive via AHCI in EFI shell, is there any read/write interface used for this purpose ?
That is, does EFI shell application need to implement the AHCI spec to access drive ? (build command, issue command and process the command completion...)
Or application just calls specific "read/write" interfaces(like SCSI_PATH_THROUGH in Windows) and the "EFI ahci driver" converts these to low-level access routines ?
If there is a driver available for the SATA drive in your UEFI, and the filesystem you wish to access is supported, then the act of reading/writing files is done by simple(ish) protocol calls.
The best example of this I can think of is the Linux kernel stub loader (which turns the Linux kernel into an EFI apllication able to load itself). Make sure to use a current 3.15 rc or later though, since there was a bug in earlier code.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/efi-stub-helper.c?id=refs/tags/v3.15-rc5 uses functions defined in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/compressed/eboot.c?id=refs/tags/v3.15-rc5 to do its file system accesses.
Alternatively, an application could do like GRUB and use methods for raw block device accesses - enabling the application to access filesystems not supported by UEFI itself.
And also, some applications (like rEFInd) enable additional filesystem support in UEFI by loading protocols (provided with the installation of rEFInd) at runtime.