cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
381 Views
Registered: ‎09-30-2011

UartLite Use as a Kernel Module

Jump to solution

We have a Zynq-based system that for a variety of necessary reasons operates in the following sequence that we cannot change

  1. Run uboot
  2. Run Linux kernel
  3. Load FPGA bitstream
  4. Load kernel modules

The device tree that is part of the kernel instantiates everything in the system including some PS-and PL-based peripherals. The system works fine.

Recently, I had to add a UartLite to the mix which, of course, lives in the PL. I added it to the device tree,  built the driver as a kernel module and added it to the list of kernel modules to be loaded after the bitstream

When I run the system, it hangs on boot after the message

"udevd: starting eudev-3.2"

which, coincidentally, is when the uartlite is loaded by the system.

If I load the bitstream first (which I can do by a series of undesirable hacks) then it boots without a problem. I suspect that the issue is that having the UartLite instance in the device tree seems to kick off a probe that requires that the UartLite instance be present - which it would not be if the bitstream is not loaded.  At least that's what I think ...

How can I convince the system to not probe the UartLite until I want it to? (i.e., when I do a modprobe)

0 Kudos
Reply
1 Solution

Accepted Solutions
Moderator
Moderator
256 Views
Registered: ‎02-07-2018

HI neil@formidableengineeringconsultants.com 

You should load the bitsteam before loading the linux,otherwise it will hang. 

If you want to load the bitstream from linux then please  follow below steps mentioned in this link using device tree overlay.

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841645/Solution+Zynq+PL+Programming+With+FPGA+Manager

 

Thanks & regards

Aravind

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
---------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
Reply
3 Replies
Mentor
Mentor
304 Views
Registered: ‎06-10-2008

How about setting the status in the device tree to disabled?

0 Kudos
Reply
Moderator
Moderator
257 Views
Registered: ‎02-07-2018

HI neil@formidableengineeringconsultants.com 

You should load the bitsteam before loading the linux,otherwise it will hang. 

If you want to load the bitstream from linux then please  follow below steps mentioned in this link using device tree overlay.

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841645/Solution+Zynq+PL+Programming+With+FPGA+Manager

 

Thanks & regards

Aravind

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
---------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
Reply
218 Views
Registered: ‎09-30-2011

Thanks for the responses. Making the device disabled in the device tree will not instantiate the device at all making it always unavailable so that won't work. Some device drivers are built to allow deferred loading. This is true of the DMA, I2C and SPI drivers and that is why I can defer loading of the bitstream and load the drivers afterwards for those. The Uart Lite, however is not built that way. That means it does not support deferred loading out of the box. To pursue deferred loading for this device it looks like the only workable solution is to use device tree overlays as suggested. While complicated, they do provide the flexibility that is needed.

It turns out that the end-user requirement of using the Uart Lite was only for a short-term experiment and so I hacked the system to load the bitstream first.

Thanks again for your help

0 Kudos
Reply