Different physical address in driver compared to userspace?

Hello,

In the workshop WS3, the offset for demo_driver is:

… qsys_headers/hps_0_arm_a9_0.h

#define DEMO_DRIVER_SUBSYS_0_BASE 0xff230000

While in HPS BRIDGE demo_driver has a different offset"

… qsys_headers/hps_0.h
#define DEMO_DRIVER_SUBSYS_0_BASE 0x30000

I then see that the userspace driver which does mmap use 0xff230000 (page 60 in workshop), while the driver uses 0x30000 according to device tree:

demo_driver_subsys_0: driver@0x100030000 {
compatible = “demo,driver-1.0”, “demo,driver-1.0”;
reg = <0x00000001 0x00030000 0x00001000>;

As far as I understand the physical address should be the same for both (kernel and userspace), so I don’t understand why driver use different physical address than the userspace.

Thank you,
Ran

Ran,

Short answer is in the MMAP example the address is “raw” and used directly. In both cases the address of DEMO_DRIVER_SUBSYS is the same 0x30000. However, in MMAP you’ll notice that the base address of the H2F LW AXI bridge is added to that, 0xFF200000 + 0x30000. Coming from the device tree the devices are organized under the bridge that they are connected to.

Near the top of the device tree look for “arria10_hps_0_bridges” and you should see the address of the DEMO_DRIVER_SUBSYS under the ranges entry too. That maps it to the correct bridge.

It would look something like: “<0x00000001 0x00030000 0xff230000 … >,”

-Steve

1 Like

Hi Steve,

Thanks a lot for the reply.
Just to be sure:
Is the physical address( in both cases) 0x30000 or 0xff230000 ?

Regards,
Ran

Hello Steve,

Do you know what’s the meaning of 0x100000000 address ?
For example in following example there is “driver@0x100030000” ? (as if address 0x100000000 is added with 0x30000)
This is my device tree example:

   demo_driver_subsys_0: driver@0x100030000 { 
        compatible = "demo,driver-1.0", "demo,driver-1.0"; 
        reg = <0x00000001 0x00030000 0x00001000>; 
        interrupts = <0 48 4>; 
        clocks = <&clk_0>; 
     }; 

Regards,
Ran

I hesitate to answer because I am not 100% sure but…I believe it corresponds to the “axi_h2f_lw” bridge being selected for that component.

Using this device tree blurb I will explain the best that I understand it:

arria10_hps_0_bridges: bridge@0xc0000000 {
compatible = “altr,bridge-16.0”, “simple-bus”;
reg = <0xc0000000 0x20000000>,
<0xff200000 0x00200000>;
reg-names = “axi_h2f”, “axi_h2f_lw”;
clocks = <&clk_100 &clk_100 &clk_100>;
clock-names = “h2f_axi_clock”, “h2f_lw_axi_clock”, “f2sdram2_clock”;
#address-cells = <2>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0xc0000000 0x00004000>,
<0x00000001 0x00000000 0xff200000 0x00000008>,
<0x00000001 0x00000010 0xff200010 0x00000010>,
<0x00000001 0x00100000 0xff300000 0x00000030>;

In “reg” there are two bridges defined: the first starts at address 0xC0000000 and spans 0x20000000 the second starts at 0xFF200000 and spans 0x00200000. Matching those two entries with the two names specified in reg-names we see that the first is “axi_h2f” the second is “axi_h2f_lw”. So further down under “ranges” the entries are formatted as such “bridge bridge_address global_address span”.
Bridge = 0x0000001
Bridge Address = 0x00000010
Global Address = 0xFF200010
Span = 0x00000010

Making the first entry of that 0x00000001 and identifying that that device is connected to the axi_h2f_lw bridge. This is as opposed to being 0x00000000 and connected to the axi_h2f bridge as the first entry in ranges does.

1 Like

Hi Steve,

Thanks for the clarifications.

But I can’t find the dts file in example zip ( I only have fractions of it in link: https://rocketboards.org/foswiki/view/Documentation/WS2LinuxKernelIntroductionForAlteraSoCDevicesLab4SoCFPGALinuxKernel).

Where can I find link to workshop’s material ?

Another question on dts: Do you also know what’s the meaning of 0x100000000 offset in “driver@0x100030000” ? (as if address 0x100000000 is added with 0x30000). I can’t see it explained in workshop.

demo_driver_subsys_0: driver@0x100030000 {
compatible = “demo,driver-1.0”, “demo,driver-1.0”;

Thank you!
Ran

Sorry…after all that I didn’t connect it back to your question. To answer that I do believe it is an addition of the bridge and bridge address to get the 0x100030000 number.

As far as the device tree - I dont have much experience with the “new” style of device tree where it is split among multiple files that include each others/common pieces. If you look into the links on that page and trace the included device tree files i think you will be able to assemble it all together. For example, go in and open up arch/arm/boot/dts/socfpga_cyclone5.dtsi and poke around.

Hi Steve,

Thank you a lot for ansering my questions.

One last thing if I may…
I can’t find sopcinfo or dts files (but only fragments of dts in rocketboard web).

Is there some zip which contains all material in workshop which contains soc_system.sopcinfo or dts files ? I could only find examples.tar.gz which contain only the drivers/demos, but not sopcinfo or dts .

Regards,
Ran

Does the workshop come with a firmware project too? Building that Quartus project will product the sopcinfo file automatically and from there you can generate the DTS file from the tutorial page: https://rocketboards.org/foswiki/view/Documentation/WS2LinuxKernelIntroductionForAlteraSoCDevicesLab4SoCFPGALinuxKernel

Check you kernel installation directory for the dti files too they will be under linux-socfpga-socfpga-4.1.22-ltsi/arch/arm/boot/dts/socfpga**dti (for whatever board you are using). I.e socfpga_arria10.dtsi

1 Like

Steve,

Thanks a lot. That was really helpful.
The workshop material is all in web and free, as I understand.

Thanks,
Ran