Different physical address in driver compared to userspace?

#1

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

#2

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
#3

Hi Steve,

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

Regards,
Ran

#4

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

#5

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
#6

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

#7

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.

#8

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

#9

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
#10

Steve,

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

Thanks,
Ran