I'm studying making an ethernet device driver in linux. Now, i confirmed that functions like probe, remove, .ndo_open, .ndo_stop work, but i couldn't see that .ndo_start_xmit works.
I want to know what kind of steps are required for .ndo_start_xmit to be called.
Related
I am trying to make some custom firmware for a MIDI controller (AKAI LPD8).
There is an STM32F102R8T6 chip in the unit.
I am trying to reach it with a programmer to wipe it, but it seems to not be responsive.
Some information and thing I have tried:
The firmware that came with the unit works, so the chip is not broken
Removed the components connected to the programming pins (PA9-PA10 and PA13-PA14)
I am able to pull BOOT0 high and have it not run the main program, but I am however not able to get a life sign using either an ST-Link2(clone) connected to PA13/14, nor a USB to serial adapter connected to PA9/PA10, so I am not sure what mode it is in
The connection has been checked, and RX-TX etc is the correct way around (but also for the sake of trying it all, I reversed the connections as well...).
Tried both the STM32CubeProgrammer and stm32flash, but none connects.
I am actually not sure if AKAI have locked the chip in such a way that you cannot even do a full chip erase and use the chip for something new? The NRST pin is strangely not doing anything to the running of the firmware either when I try to pull it low.
Is there a way to reprogram these chips when they come off of a commercial product, or are they permanently locked?
Any solution/tips?
Many of the STM32 parts have "proprietary code read-out protection" (google PCROP) which but you might be lucky and they haven't enabled it in the option bytes. Read the documentation for that and the bootloader documentation and get a good idea of what you expect it to do if it is enabled and if it isn't.
If you have a scope, try watching the SWD/JTAG pins to see if there is any response from the device. (If you aren't even sure if it is in reset then scope the crystal if there is one).
If you haven't got a scope, you might be able to to verify what it is doing by seeing if it sets the pins and pull-resistors to how they would be expected to be in the bootloader mode, eg: UART TX should be high if it is enabled, even it it isn't transmitting anything. Put a strong pull-down (~1k) on there and see if it still reads high.
After hours of trying different ways of making it work (also tried the alternate mapping of the UART port), and probed the TX pin as suggested by Tom V to no avail, I have given up working on that specific chip and ordered an upgrade from the STM32F4 family instead to replace it with. A lot more power and useful peripherals.
A bit of a non-answer to the specific question. Frustrating to not have found out what was wrong (chip or approach) but being mindful of the sunk cost fallacy, I think it was best to just replace the chip with a fresh one and start development from there.
Is it possible to connect and disconnect to some available network connection with swift, cocoa?
///Addition
So.. I found the NSNetworkInterface, but can't understand how to turn it on or off. Need some little example, just explain, what call -> what get
Is it possible to connect and disconnect to some available network connection with swift, cocoa?
You can't do any of this on iOS, of course, since your code will never run with sufficient privileges and the necessary frameworks probably aren't available. You asked about Cocoa, though, not Cocoa Touch, so I'm presuming you're talking about MacOS X.
I assume that you mean actually connecting to a network rather than just connecting to some host over an established network. To do that, you need to change the system configuration. It is possible to do that, although you'll need to work at a lower level than Cocoa and instead use the SystemConfiguration framework to change the configuration registry. Your code will have to be running with root privileges in order to work, and that alone may make the process untenable depending on your situation. You can find complete instructions and code at Programmatically changing network configuration on OSX. Note that the article dates from 2011, so it's possible that things have changed enough that the advice there no longer works, but it will at least point you in the right direction.
The article obviously predates Swift, but I don't see anything there that wouldn't work in Swift.
I've got a Behringer X32 rack, which uses an extension of the OSC (Open Sound Control) protocol. This particular rack communicates via UDP packets on port 10023. A fellow named Patrick Maillot actually has some pretty extensive albeit unofficial documentation of the protocol, including multiple executables you can download to interact with the system (outside of the official Behringer apps).
What I would like to do is pretty simple, though I'm having a hard time getting up to speed with this. I want to be able to mute and subsequently un-mute Mute Group 1 on my device. The mute group is already set up; all I want to do is utilize the protocol to either activate or deactivate it.
I can successfully connect to the rack using the X32_Command.exe program. But wading through the documentation, here's what I came up with as my best guess for which commands I should be sending:
/config/mute/1/ON
/config/mute/1/OFF
However, I don't think I have the syntax right (or maybe I've just got the wrong set of commands altogether), because those don't seem to do anything. In the X32_Command.exe console application I appear to receive the following responses when issuing those commands, respectively:
->X, 20 B: /config/mute/1/ON~~~
->X, 20 B: /config/mute/1/OFF~~
However, nothing actually happens on the rack. The mute group isn't affected at all when I issue these commands. How do I get this working? What am I doing wrong?
Just saw this (better late than never). The correct syntax for X32_Commmand.exe would be (as stated in the documentation):
/config/mute/1 ,i 0
/config/mute/1 ,i 1
Normally in Linux PCI drivers may expose a control interface to user-land
via a character device, e.g. /dev/drv_ctl, and a user application can
read/write I/O control commands with ioctl() on the open file descriptor.
In Linux we create this with register_chrdev() kernel API.
I would like to have the same or similar mechanism and behaviour on Solaris, but seems that on Solaris it works slightly different; DDI routine ddi_create_minor_node() requires a node type indicating audio, block, net etc. device, this looks quite vague to me, for example what type a crypto PCI device belongs to?
Also, it seems that ddi_create_minor_node() creates a node under /devices/* and not under /dev/*
I would appreciate if someone could clarify my doubts and point out at the right directions.
Thanks.
Typically you create a symlink under /dev yourself, using a name which is useful to you. That would point to your actual /devices path which was created by calling ddi_create_minor_node(). You'll find the list of ddi node types in <sys/sunddi.h>; for a crypto device (what even is that?) you'd probably want DDI_PSEUDO.
I have written a Loadable Kernel Module (LKM) which wraps the audio-driver under /dev/snd/pcmC0D0p .
Therefore I moved pcmC0D0p to pcmC0D0p_bak, renamed my driver to pcmC0D0p and passthru every command like MMAP, IOCTL etc. (but doing other things before forwarding the MMAPed-data).
This is bad, I know (but it's my first step in linux-programing) but it worked.
Today, I read in an article about Userspace device drivers.
Now I'm wondering: should this really be possible? Write a "driver" with userspace-code, implemented methods like MMAP & IOCTL and put it in place of a normal kernel-device (/dev/snd/pcmC0D0p)?
It isn't, isn't it?
IF it's possible, has anyone a simple example, a reference? Anything is really welcome!
It is possible to write userspace device drivers, but not quite in the way you're thinking.
An example is the uio_pci_generic module, this can be programmed (via /proc) with the ID of a PCI device and will make the device's memory available to you via mmap. You can receive interrupts by blocking on a read call.
Note how this does not allow you to pretend to be a driver, only to perform driver-like actions (communicating directly with a hardware device, receiving interrupts, etc). No userspace program can ever service a call to ioctl, or expose itself as a character device, without the help of some kernel module.