I have a simple question regarding U-boot driver model. I wanted to know when and how function ops of a driver is triggered.
For example for Ethernet driver these are the ops defined:
static const struct eth_ops designware_eth_ops = {
.start = designware_eth_start,
.send = designware_eth_send,
.recv = designware_eth_recv,
.free_pkt = designware_eth_free_pkt,
.stop = designware_eth_stop,
.write_hwaddr = designware_eth_write_hwaddr,
};
Now , are these eth_ops are called at initialization stage after probe function or these are called only when some commands are run from u-boot prompt like ping , tftp etc?
Initialization stage would only probe the device and move it next subsystem ?
It depends on u-boot settings. If the bootcmd and bootargs environment variables define something related to the network like loading the kernel from tftp server it will first call the start callback and on sending and receiving the send/rec callbacks. If the kernel is loaded from flash u-boot networking is not required and if you're not using network commands on uboot shell no callback is called
Uboot drivers model is very similar to Linux model and actually there are a lot of common code between them. The only "big" difference is that uboot uses physical addressing and Linux uses MMU to convert physical to virtual address space
Related
I am writing a bootloader for my Arm board (32-bit i.MX6) and want to boot the Linux kernel using a device tree and an initrd file located at a static location in memory.
I looked to U-Boot as a reference and I see I can use the bootm command to provide a kernel, device tree and ramdisk:
Boot application image from memory:
bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg
...'; when booting a Linux kernel,‘arg' can be the address of an initrd image
I know there are two ways to pass information from a bootloader to the kernel, the legacy ATAGS method and the modern device tree method.
With ATAGS this can be achieved with the ATAG_INITRD2 tag which describes the address that a ramdisk is stored in memory. However, with a flattened device tree no ATAGS are passed to the kernel (which is shown in the boot log with the "No ATAGs?" message). I do not see any method to specify a ramdisk when using a device tree.
If I look at the documentation for booting the Linux kernel on Arm I see the following interface is specified:
- CPU register settings
r0 = 0,
r1 = machine type number discovered in (3) above.
r2 = physical address of tagged list in system RAM, or
physical address of device tree block (dtb) in system RAM
In fact, the same document states that an initramfs must be configured prior to booting, yet includes no details on how to do so when booting with a device tree.
Is there some alternative way to achieve this? Is the required information appended to the device tree automatically by U-Boot, or is there an alternative way to notify the kernel of the ramdisk location?
It will be patched in the dtree by the bootloader; e.g.
/ {
chosen {
linux,initrd-start = <0x....>;
linux,initrd-end = <0x....>;
};
I'd like to access to PCIe IO from userland.
In the module driver, I'm able to write/read using the pointer returned by ioremap () without any problem.
From userland, I want to use the pointer returned by mmap () but the host hangs whatever I write or read on the PCIe bus.
I implemented the mmap call in the file operation structure which calls io_remap_pfn_range(vma, vma->vm_start, start >> PAGE_SHIFT, vma->vm_end - vma->vm_start, vma->vm_page_prot); where start is the value returned by pci_resource_start ().
What did I miss ?
Note that my module works fine on x86.
Thanks,
Fred
The POWER architecture does not support PCIe IO accesses; you'll need to use PCIe memory cycles instead. It's likely that your PCIe device has a corresponding resource for MMIO space, perhaps you can use that.
Also, depending on your usage, you may want to perform accesses on the resource<N> files in sysfs, under /sys/bus/pci/devices/<id>. This might mean that you don't need any kernel code at all.
I am trying to learn User mode driver to receive interrupts of my Network Card.
I insmod two kernel components ${KSRC}/drivers/uio/uio.ko and ${KSRC}/drivers/uio/uio_pci_generic.ko.
But I donot see any device getting created which I can then mmap
Typically for UIO I would need something like "/dev/uio0" which I can open then mmap()
So how to go about using UIO framework?
Edit:
My network card is Marvell ethernet controller. My hardware is x86 Ubuntu. Linux kernel 3.13.11.11. So no device tree based.
First of all, the driver has to be compiled into the kernel. Either use menu config or add the following lines to a .cfg file. You can check that the driver has been compiled by looking in /lib/modules/<kernel-name>/modules.builtin.
CONFIG_UIO=y
CONFIG_UIO_PDRV_GENIRQ=y
The next step is to add the following entry to your device tree You can check that the driver has been compiled by looking in /lib/modules/<kernel-name>/modules.builtin.file. Where the middle number is the interrupt you are targeting -32. This means 0x1D == 29 and then add 32 for the interrupt number that is registered in the GIC (Generic Interrupt Controller on ARM systems).
spw0#7aa00000 {
compatible = "generic-uio";
reg = <0x7aa00000 0x10000>;
interrupts = <0x0 0x1D 0x4>;
interrupt-parent = <0x3>;
clocks = <0x1>;
};
and changing the bootargs to console=ttyPS0,115200 root=/dev/mmcblk0p1 rw rootwait earlyprintk uio_pdrv_genirq.of_id=generic-uio.
If everything goes well, you will see the /dev/uio0 device after booting up.
I have developed a working driver for my custom_hardware that relies on the device tree. Because my driver may evolve, I do not want my driver to be part of the kernel (when I say 'be part of the kernel', I mean, to be compiled with the kernel during the kernel creation)
Here is a glimpse of my dts:
custom_hardware: custom_hardware#0x41006000 {
compatible = "mfg,custom";
reg = <0x41006000 0x1000>;
#interrupt-cells = <0x1>;
interrupt-controller;
};
existing_hardware: existing_hardward#41004000 {
compatible = "mfg,existing";
reg = <0x41004000 0x1000>;
interrupt-parent = <&custom_hardware>;
interrupts = <0>;
};
The existing_hardware's driver is already compiled with kernel (the existing_hardware's driver has been compiled with the kernel during the kernel creation).
What I would like to do is to append my custom_hardware's driver to the ramfs and let the kernel loads the custom_hardware's driver prior of the existing_hardware's driver.
This is important since the existing_hardware's driver requests a virq from the irq_domain of the custom_hardware's driver. In order to get the irq_domain, the custom_hardware's driver must be loaded first.
Note that the existing_hardware's driver gets loaded during the probing of the device tree which seems to happen in the early stage of the kernel booting sequence.
That is not the way to do. The order of the module/driver loading must not matter. What you need to do is return -EPROBE_DEFER when getting the IRQ fails in existing_hardware. Then it will get probed again at a later time, hopefully after custom_hardware got probed.
Also, you can apply that patch that will ensure that request_irq() fails because the domain is not present yet and return -EPROBE_DEFER in that case
https://lkml.org/lkml/2014/2/13/114
I had similar problem (probing order was wrong) and the only simple solution what I found is put the modules in the desired probing order into the Makefile.
I've found the solution here: What is the Linux built-in driver load order?
I am learning linux network driver recently, and I wonder that if I have many network cards in same type on my board, how does the kernel drive them? Does the kernel need to load the same driver many times? I think it's not possible, insmod won't do that, so how can I make all same kind cards work at same time?
regards
The state of every card (I/O addresses, IRQs, ...) is stored into a driver-specific structure that is passed (directly or indirectly) to every entry point of the driver which can this way differenciate the cards. That way the very same code can control different cards (which means that yes, the kernel only keeps one instance of a driver's module no matter the number of devices it controls).
For instance, have a look at drivers/video/backlight/platform_lcd.c, which is a very simple LCD power driver. It contains a structure called platform_lcd that is private to this file and stores the state of the LCD (whether it is powered, and whether it is suspended). One instance of this structure is allocated in the probe function of the driver through kzalloc - that is, one per LCD device - and stored into the platform device representing the LCD using platform_set_drvdata. The instance that has been allocated for this device is then fetched back at the beginning of all other driver functions so that it knows which instance it is working on:
struct platform_lcd *plcd = to_our_lcd(lcd);
to_our_lcd expands to lcd_get_data which itself expands to dev_get_drvdata (a counterpart of platform_set_drvdata) if you look at include/linux/lcd.h. The function can then know the state of the device is has been invoked for.
This is a very simple example, and the platform_lcd driver does not directly control any device (this is deferred to a function pointer in the platform data), but add hardware-specific parameters (IRQ, I/O base, etc.) and you get how 99% of the drivers in Linux work.
The driver code is only loaded once, but it allocates a separate context structure for each card. Typically you will see a struct pci_driver with a .probe function pointer. The probe function is called once for each card by the PCI support code, and it calls alloc_etherdev to allocate a network interface with space for whatever private context it needs.