I am trying to implement a RPC mechanism in an embedded SoC. The SoC has a dual-core cortexA9, with one core running ThreadX and the other running Linux 3.8.
My question is:
Is Sunrpc a good choice for this?
As far as I know, sunrpc on Linux only supports UDP/TCP transport. Is it possible to add a proprietary transport? Is so, do I have to hack both user-space and kernel code?
Thanks
Joey
Related
Helo All,
I am trying to learn embedded linux.
Please provide clarity on below:
As DTB provides Board and SOC related information will it be sufficient to make sure correct drivers will be enabled?
How a correct driver will get selected and will it happen during build time or kernel runtime based on the DTB?
How are drivers for platform devices(UART, SPI, I2C etc) handled in Linux? I mean as different SOC's have different implementations(register and bit fields will be different) of these peripherals how a single driver will be able to handle both SOC's?
Is it sufficient to have well defined DTB about board and kernel to make Linux up and running on any platform.
Thanks,
Suraj
I have a fairly large PCIe driver written on/for Linux, now I need to port it on FreeBSD. I don't yet know the BSD version, but I think at this point it's irrelevant, as I'd like to understand in general what major items will have to be modified during the porting efforts.
The good thing is that the driver is partitioned into OS independent "library" layer (OSI) and OS dependent, so it already has a "framework" permitting to port it on other OS-es, and I hope most of the efforts will be focused on OSI side. So far I see the following big chunks of work:
init code, i.e. the OS-specific code that "plugs" the driver into
system (similar to what init_module, cleanup_module does in Linux)
code registering driver in a PCI core subsystem of the kernel
character driver registration code 4) DMA operations
What else should I be paying attention to? This driver is a device doing hardware encryption, so it is offload device (ingress packets from NIC enter system normally and then diverted to the device).
If there are useful web links to description of BSD drivers development/porting (similar to LDD), I'd happily accept it :)
In 2011, Jeff Roberson (and later Mellanox) added some shims to ease porting Linux drivers, which makes most of the code be used as-is, when he ported the Linux InfiniBand drivers to FreeBSD. So, assuming I am some newcomer from Linux driver development world, I'd start by looking at:
https://svnweb.freebsd.org/base/head/sys/ofed/include/linux/
Where you would find implementations of many required Linux driver API and their FreeBSD native counterpart.
There is another quickstart document by John-Mark, here, helpful for those who are already familiar with driver writing.
If you would prefer starting from the beginning, I think the FreeBSD Architecture Handbook would be an useful start point.
Additionally, there is a book by Kirk McKusick, Robert Watson and George Neville-Neil, titled "The Design and Implementation of the FreeBSD Operating System", the latest version at this time is 2nd edition, and the chapter 8 detailed device drivers.
Most device drivers are merely wrappers of hardware operation to fit OS interfaces, so a well layered driver should be relatively easy to port nowadays.
If you have questions, or is a vendor of hardware, you can also join various FreeBSD mailing lists (freebsd-drivers#, etc.).
Sorry for the long description of my problem :-)
I have been handed a task to perform simple reads and writes to/from an I2C device on our new PC based board design. The board will be built using Portwell's Qseven mini PC which uses an Intel Tunnel Creek (ATOM) processor (essentially an x86 processor) and an EG20T IOH chip.
The I2C slave device is a TI AIC3254 audio codec. OS is Ubuntu 10.04 LTS 32 bit.
uname -a
Linux Torchwood 2.6.32-41-generic #88-Ubuntu SMP Thu Mar 29 13:08:43 UTC 2012 i686 GNU/Linux
The PC portion of this device will be essentially a general purpose PC.
The PC/OS needs to load the codec (registers) via I2C at system init. After that the codec will be controlled by an Atmel processor which will be a second master on the I2C bus (remaining silent until init is complete). The ATOM will have no additional direct interaction with the AIC3254.
All that I need to do, as far as I know, is to copy the codec's "program" to it over the I2C bus then read it back (poor man's load check).
It seems the logical approach is to use a userspace program to talk to the AIC3254 rather than try to create a device driver. However, after I modprobe i2c-dev; depmod -a no I2C bus appears in /dev and i2cdetect from i2c_tools finds no buses (devices?).
What I need is some understanding of Linux I2C access coding. Complete noob here.
Do I need a device driver after all? I don't need any fancy interface for general programs too use, just one simple read/write to bus/page/register. Perhaps a simple char mode driver? I've read something that suggests such things exist.
Do I need to put a *new_device* and *delete_device* file in /sys/bus/i2c/devices/i2c-0/?
Even with i2c-dev.ko installed no i2c-x "file" appears in /sys/bus/i2c/devices/ What am I missing here?
Can I assume or find out if this kernel knows about EG20T IOH chips? Or are these chips generic enough that i2c-dev can deal with them?
Will I need i2c-core.ko? It isn't found on the Ubuntu image. What do I need to apt-get to have it if I need it?
Do I have any use for the i2c-algo_???.ko's?
Sorry to be such a noob. Thanks for any help.
I think you need to add i2c support in your board support file when you build the kernel for the target. We use an Atmel based board to do i2c, and during kernel init, it calls i2c_register_board_info() to register the i2c devices. Then you can access them using i2c-tools, and userspace apps. Note we are using 3.2.6 kernel, but similar calls are likely needed for 2.6 kernels
In Linux user space programming, we use RPCGEN for RPC programming. In Linux Kernel module, is there any interface like RPCGEN for programming?
NFS client (and server as well) is kernel-based and NFS protocol is based on Sun RPC, so have a look at it's implementation.
I am using Linux SCTP Stack. Currently on the same Linux machine I need to deploy a process which uses non OS SCTP STACK. (i.e. it opens a RAW socket and then handles transport level message on its own).
When SCTP Init comes Linux gives the packet to both processes.
Can this be avoided?
I don't want Linux SCTP to handle message which are not used by it. (used by other Non OS SCTP Stack)
Is this possible?
More generally when faced with this kind of issue there are three options:
1) Stop the Linux SCTP module from being loaded at boot time (Note: it cant be unloaded at run time) and just use the non-OS implementation.
2) Some how preconfigure each SCTP implementation to know which associations it owns and to ignore messages for others.
3) Port the non-OS system to use the Linux implementation.
Any actively supported Linux system using SCTP is going to have issues if it does not offer the third option.
Note: If you are using the Dialogic Non-OS SCTP implementation on Linux then you can easily switch to using their OS wrapped version 'SCTPN'.
Regards
This may not be an option, but having the non-lksctp process use UDP tunnelling of SCTP works very well for us. The (commercial) stack we use is configurable for SCTP over UDP, or SCTP over IP (with raw sockets, like you).