Hi,
to implement custom peripherals in bare metal is no problem, but what if one want to implement a peripheral as a driver for the embedded linux?
I'll be grateful for any help,
Gerd
Hi,
to implement custom peripherals in bare metal is no problem, but what if one want to implement a peripheral as a driver for the embedded linux?
I'll be grateful for any help,
Gerd
This way has worked for me,
Add your peripherals in the .dts-file, e.g. for my motor-controller block I add (under the AMBA/AXI-bus depending on which release):
motor_control_bdc_6wheels@40000000{
compatible = "digster,motor-control-bdc-6wheels-1.00.a";
reg = <0x40000000 0x1000>;
};
where the reg-parameter specifies the <baseAddress memorySpace>.
For writing the actual driver, I used http://wiki.xilinx.com/gpio-user-space-app to create a user-space driver. Not optimal but still... More information is available in other topics about ioremap() e.g.
This (http://www.zedboard.org/content/recompile-linux-kernel) forum thread helped me a lot when customizing the Linux experience.
TY for the help.
Where did you get:
motor_control_bdc_6wheels@40000000{
compatible = "digster,motor-control-bdc-6wheels-1.00.a";
reg = <0x40000000 0x1000>;
};
from?
But in order to make the dtb file consistent with the pl portion i have to modify the boot file with the .bit file for the configuration, right?
motor_control_bdc_6wheels is the name of my IP-block name. @40000000 is just the HEX address. Inside the {} i just tried to edit another entry to fit my block. The compatible somehow points to the driver/developer of the block, and I wrote it as "project name,driver name".
The reg parameter is just <base address, address space>
Regarding the bit-file/dtb-file consistency, the dts/dtb should of course be representing your current bit file (not entirely necessary but should be). So yes, the boot.bin needs to be updated with your *.bit-file.
However, I think (not entirely sure, could check later) that the device-tree could be left as it is as long as you are providing your own driver with HARD CODED addresses and such. The device tree is only for writing generic drivers. (Someone else might say that I'm wrong about this however...)
It worked, i implemented the simple_register example as linux driver with your guidance, but when it came to the software i sticked to this: http://wiki.xilinx.com/osl-user-mode-pseudo-driver
and i managed to strip the out put of the register to the leds. now that this is working, other things will work as well in the future
Hi Gerd86,
I am trying to do the same with no luck. I am trying to implement the simple register in linux but get a segmentation fault when I try to read/write it. Can you provide the source code of what you did to get it to work? Thanks.