I'm pretty new to the Linux device tree, and I am searching for a way to disable the SD Card Interface on my Linux embedded system.
I recently figured out how to disable my USB Interface by unbinding it's device driver, using echo -n 1-0:1.0 > /sys/bus/usb/drivers/hub/unbind
Now I am trying to do the same for the SD Card slot, but I am running into problems finding the correct path/driver to unbind. I believe the device is located in /sys/block/mmcblk1, but I'm not really sure how to go about finding the correct device id/unbind file. Any tips on disabling an SD interface?
Edit 1: Upon further inspection, mmcblk1 doesn't even show up when there is no SD card inserted in the slot. How should I go about disabling the interface itself, not just disabling a single card?
Edit 2: It looks like disabling hotplugging might work, but I am now struggling to understand mdev rules.
Edit 3 (Solution): After slogging through the device tree, I was able to track down the specific device and driver combination that was running my mmc reader. echo -n mmc1:aaaa > /sys/bus/mmc/drivers/mmcblk/unbind is able to unbind the driver from the device (mmc1:aaaa). I also had to tweak my mdev rules, as the driver was reloaded every time I plugged in my device. The final solution was to drop the following into /etc/mdev.conf: mmcblk([1-9]+) root:disk 777 #echo -n mmc1:aaaa > /sys/bus/mmc/drivers/mmcblk/unbind, which runs every time an mmc device binds (excluding mmcblk0, as we are using that elsewhere) and immediately unbinds the driver.
You can try blacklisting /lib/modules/$(uname -r)/kernel/drivers
/mmc/core/mmc_block.ko.xz.
Create the file /etc/modprobe.d/blacklist_sdcard.conf and add the line: "blacklist mmc_block" without the quotes, and then reboot.
Note that this might disable other devices on your system if something else uses it, so you might discover you've created a problem.
edit
Sorry the above didn't work for you. I was also concerned that other things were using the device driver.
This should do it:
Create /etc/udev/rules.d/99-disable-automount.rules
and add the line:
ACTION=="add|change",KERNEL=="sdb",ENV{UDISKS_IGNORE}="1"
using whatever device the card reader mounts as for the "KERNEL==" section.
Then do udevadm control --reload
and you should be all set.
Related
I want to create an application or modify USB in a way so that, upon insertion into any PC, I can get the information that PC was inserted.
eg. upon insertion, I can read PC name and make an API call with this as post data so I'm able to know that my USB was inserted in some PC. But this should happen right away as USB is read by the machine, so even if the user formats it thereafter, it should not matter.
If it was earlier windows, I could write autorun and that would work. But I want this detection mechanism for Windows 7 and above.
I have done some research on the topic but could not find any reliable content. Some articles were related to USB based hacking attacks by changing wiring (USB hardware, to harm the computer) or something like that. But I totally don't want to do that. Just the detection, that USB was used.
I am trying to do OSX's internet sharing from the command line and there doesn't seem to be a command for it, so I'm trying to do it manually by turning the network card to access point mode. I can't seem to find anything about how to turn the wireless card into AP mode on the mac. Linux would use iwconfig (which OSX doesn't have) and I've monitored the files that network sharing opens, but no dice so far.
It looks related to wifid, but the documentation for wifid only says "Don't invoke wifid directly". Also played with the airportd command, but it doesn't seem to let the card go into AP mode. There must be a way to do it, since internet sharing creates an access point.
TL;DR:Does anyone know how to turn on Internet Sharing from the command line?
I have a PCI driver for a FPGA card that installs and works fine.However, we have a need to clean up our system without rebooting which includes unloading this driver.
When starting again (without rebooting) the driver is re-installed. I have found that when I do this process (install/uninstall) multiple times, on the 5th unload of the driver the directory associated with the device just disappears.
lspci command can no longer find my device because of a bad link. I have to reboot to get the device directory (/sys/bus/pci/devices/00000:04:00.0) to show up again.
With some experimentation and reducing the driver down to the bare minimum I discovered that if I do not do a call to pci_enable_device(..) function in my pci_probe_method, then I am able to install/uninstall the driver multiple times without error.
Of course, I need to call this method before I can do anything with the device but I wanted to be sure it was not some other of the more complex initialization I am doing was causing the problem.
I have verified that my call to pci_disable_device() is being called in the pci_remove_method(). I should be able to enable and disable a PCI device indefinitely, right? Any help in figuring out what is happening would be appreciated.
The actual solution to this problem was to eliminate an extraneous call I had to pci_dev_put(..). I did not notice this before when submitting the question. This was leftover from when this driver was not using the pci_probe() method to discover this device. So, executing this call in the exit routine caused the structure for this device to go away after 5 calls. So for now this problem is solved.
Got a customer request but no idea can it be done. So need your opinions on this. This might be a utterly stupid thing to ask but yet need some facts so can work out best solution.
Scenario,
My Customer is an OEM Manufacturer. They make an automated system with a embedded touch screen (Windows XPe) this system got a button panel with some LED indicators (apart from keyboard) and 7 USB Ports. These button panels and USB ports are checked before sending to QC process. Currently a USB thumb drive with standalone executable with all indicators and controls flags is inserted to one of the USBs and then will run the exe. This exe capture user inputs from button panel and indicate which button is pressed so that it can be verify as working. And from program user can set LED indicators to different states (flashing, steady and off) so they can be verified as well. Once this is done then USB thumb drive will be inserted to each port and will verify it recognise. But after each verify step it needs to safely remove the drive from task bar. Once each test is finish user required to fill up the sheet with all pass and fail states for the entire button panel, indicators and USB ports. This is a quite length process when its come to mass production.
Apart from this embedded system all other components which suppose to connect to one of above embedded systems are tested via a program which I make and records all test outputs as they are tested. This program installed and components are connected to a testing embedded system.
Requirement,
What customer asks, can my program test completed embedded system with our host system (testing embedded system, may be via USB to USB) Its more like Testing a PC from another PC. Any ideas ?
Additional Info.
Apart from USBs there is one Network Port.
Thanks for looking, Feel Free to ask any questions. Any opinion is appreciated.
I'm not an expert on this topic, but it seems like this would be problematic because USB is an assymetrical protocol. There are hosts and there are devices. Hosts make the requests, and devices fulfill the requests. The problem is that PCs are USB hosts, not USB devices, so you would have two hosts trying to get the guy on the other side to do what he wants. Testing with a USB thumb drive worked because the thumb drive is a device.
It sounds like the unit to be tested doesn't have an ethernet port, which is a shame, because that would be the easiest way to go. If it has a serial port you could do it that way, but that is both slow and a hassle.
We have an auto update for our software that is installed via USB key (with the auto run). If I wanted to ensure that only authorized USB Keys were used, what's the best way?
Our installer is already signed, and it won't run otherwise. But I'm more wanting to inspect the USB Key for a signed installer, and if it's not there, just ignore, or even "Eject" the USB device.
And I should be able to tell the difference (in code) between a usb storage device, and say a camera, or keyboard.
I'm only wanting to disable non-authorized storage devices.
Thank you for your ideas.
non-authorized storage devices? This depends on how secure you want it to be. For the most secure level, it would consist of:
special firmware written to the flash drive to get extra "meta info" (read: expensive custom manufacturing of flash drives)
special windows driver to read that meta info from the flash drive
your program talking to that device driver to confirm it's authorized.
Or to the least secure level you have these options:
using a hidden file and a special key(possibly hashed time of last filesystem modification or something?) (dd breakable)
dropping below the filesystem level and recreating your own very simple filesystem.. (more security through obscurity though and dd could break that)
Also, for the "most secure" option, you really need a more secure way of running the program than auto-run and a device driver(which could be half-baked to make anything appear authorized). Why do you want it to only update from an authorized flash drive anyway?
You might be able to read the USB drive's serial number (assuming you get USB drives that have serial numbers; not all do). Then your application could call home to get the latest list of authorized serial numbers, and check to see if there is a match.
Earlz response is good, though I don't think you'd need custom manufacturing of flash drives... you would just need flash drives with some sort of unique firmware encrypted identifier. Perhaps something in the Kingston Data Traveler Line might do the trick. (I've never actually used one of these encrypted usb sticks, so I'm a bit foggy on the actual implementation details).