Electronics > FPGA

[Solved] Cyclone V (de10-nano) SDRAM controller - how to reserve memory for FPGA

(1/4) > >>

plastygrove:
I've been able  to successfully write to SDRAM from the FPGA using a custom Avalon MM Host/Master component. This is pretty barebones and all I'm doing is writing one byte at memory location 0x20000000 (512M).

When I boot up the de10-nano in Linux, I'm able to access the byte that I'm writing using:


--- Code: ---busybox devmem 0x20000000
--- End code ---

But to make sure that I'm not overwriting anything that is already using that memory space, I added the kernel parameter in the boot options to reserve 10K.


--- Code: ---memmap=10K$512M
--- End code ---

Is this the right way to do it?

plastygrove:
Looks like the kernel parameter memmap isn't working for me. When I check in /proc/iomem, it doesn't show any reserved memory space:


--- Code: ---root@de10-15aug21:~# cat /proc/iomem
00000000-3fffffff : System RAM
  00008000-00cfffff : Kernel code
  00e00000-00eff01b : Kernel data

--- End code ---

However, I modified the device tree as shown in this post and I can now see the reserved memory in /proc/iomem. I reserved about 50MB (0x3200000) starting at 512MB (0x20000000)


--- Code: ---root@de10-15aug21:~# cat /proc/iomem
00000000-1fffffff : System RAM
  00008000-00cfffff : Kernel code
  00e00000-00eff01b : Kernel data
23200000-3fffffff : System RAM

--- End code ---

The modified device tree code I used is:


--- Code: ---#include "socfpga_cyclone5.dtsi"

/ {
  model = "Terasic DE-0(Atlas)";
  compatible = "terasic,de0-atlas", "altr,socfpga-cyclone5", "altr,socfpga";

  memory@0 {
    name = "memory";
    device_type = "memory";
    reg = <0x0 0x40000000>; /* 1GB */
  };

  reserved-memory {
    #address-cells = <1>;
    #size-cells = <1>;
    ranges;

    some_reserved: buffer@20000000 {
      compatible = "my-dev";
      no-map;
      reg = <0x20000000 0x3200000>; /* 50 MB */
    }; 
  }; 

  myfpgawrite {
    memory-region = <&some_reserved>;
    compatible = "foo";
  }; 
};


--- End code ---

Minirant: Strangely, this is not the first time that Xilinx forum posts have helped me with an Intel/Altera device. I wonder why the Intel communities at rocketboards.org and community.intel.com are dead.

Daixiwen:

--- Quote from: plastygrove on September 19, 2021, 03:05:20 pm ---Minirant: Strangely, this is not the first time that Xilinx forum posts have helped me with an Intel/Altera device. I wonder why the Intel communities at rocketboards.org and community.intel.com are dead.

--- End quote ---
I've never been at rocketboards but for the other one, alteraforums was very active and helpful but Intel killed it when they moved it to their crappy platform.

Daixiwen:
Don't forget about the data cache. When you write directly to memory with a master interface, you also need to invalidate the CPU's data cache for the area before reading it. I don't know how you do this in Linux but I assume there is an API or macros for that.

BrianHG:

--- Quote from: Daixiwen on September 20, 2021, 07:53:35 am ---Don't forget about the data cache. When you write directly to memory with a master interface, you also need to invalidate the CPU's data cache for the area before reading it.
--- End quote ---
That's cheaply designed...  Though I guess if that cache is part of the CPU core and not part of the ram controller or it's cache doesn't consider write hits within it's cache on the bus when there is an alternate master, I can see how this may be an extra step which would complicate the design.

I remember when Motorola came out with the 68040 and it's internal cache killed Amiga OS 1.3.  The only needed trick was adding 2 strategically placed 'NOP' instructions in the Amiga 1.3 ROM since with Motorola 68K line of CPUs, 'NOP' was actually not a 'NOP', but a flush cache instruction.

Navigation

[0] Message Index

[#] Next page