Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
19 years ago

Running Linux inplace, from EPCS or CFI

I have run into some problems continuing on in my development with the

Altera Cyclone II DSP dev board and uCLinux, related to memory

interfacing. (At this stage I have uCLinux running on this board and the DM9000 networking up and running.)

The Nios II instruction master cannot address more than 256 MB, and so this means that on my system I can only use 128 MB of the DDR2 DIMM. Since for this project we eventually wanted to use a 1 GB DIMM (for datalogging), this is a problem.

The only solution I can see that is possible, unless Altera fix the Nios II so it can address more than 256MB, is to run the Linux kernel in-place, either from the EPCS or an added-on CompactFlash. Then the DDR SDRAM does not have to be put on the instruction master, just the data master, and we can use the full 256MB/1GB for data.

My question is whether it is possible to do this? In a normal boot, the zImage is first copied to SDRAM, then decompressed and executed. Is it possible to store the uncompressed kernel and filesystem in flash, such that there is no need to decompress or copy to RAM for execution?

Notes:

1) Searching the web, I've found a bit of information on eXecute-In-Place (XIP), but it mostly seems targeted at ARM and MIPS based systems.

2) I do have 1 MB of SRAM which can be mapped to the instruction master as well. Ideally I will use this area to download programs via ftp so I don't need to recompile the kernel every time.

3) Building a kernel with > 64MB RAM requires patching the SystemPTF perl scripts. Let me know if anyone wants the change to go in the main distribution.

Regards,

Josh

9 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    1. there is no xip suport, and running from cfi or epcs is very slow.

    2. you should think of using nfs, IDE HDD, or IDE ram disk for data logging.

    3. try to work with what you have may be easier than asking something new from Altera.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    Thanks for the reply hippo.

    So, XIP is not supported. Running from CFI/EPCS wouldn't bother me so much, even if it is very slow. It's not the speed of the Linux system that I care about, it's the data logging in our custom peripheral that needs to be fast.

    I can't log directly to disk, as I am capturing 16-bit samples at 50 Msps. So what I was planning to do was log 10 seconds (~1 gig) worth of data to DRAM using DMA from our custom logic, and then spend 20 minutes or so writing this to a disk using FTP.

    I realise that I am going to need to work with what is available. I was just disappointed to read of this 256MB limitation. All the Nios literature I have read claims a 2 GB address space, and so it is a bit deceptive to hide away this "small limitation" in the fine print in a development kit readme.txt.

    So it looks like I am stuck with 128 MB, but thanks for the help. Such are the trade-offs of quick development time!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    I understand your problem.

    You may start working with 128MB sdram.

    It is still possible to hack the nios2/sopc build scripts, those are perl and java.

    You may try it at a later time.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    I did hack the scripts.

    In uClinux-dist-test/linux-2.6.x/arch/nios2nommu/scripts/PTF/SystemPTF/Module.pm, after line 176, in function getSize{}, I added:

    } elsif ($data_width == 64) {

    $size = 1 << ($addr_width + 3)

    } elsif ($data_width == 128) {

    $size = 1 << ($addr_width + 4)

    }

    This is required to use more than 64 MB of RAM, so I did this to use 128 MB. I can&#39;t use the full 256MB that is on the DIMM, since the other peripherals still need to be mapped into memory.

    I did think about trying to hack the SOPC build scripts. However, if there is a genuine restriction to 256MB in the instruction master of the Nios, then hacking the scripts will just break the CPU logic. I had a look at the generated VHDL, but there is just too much of it to manually edit it.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    the 256M limitation is on inst master.

    the data master shouldn&#39;t have such issue.

    so you can run uclinux on 128M,

    and use 1G-128M for data logging, which will be accessed by data master only.

    the sopc window will refuse to generate.

    but you may try to run generate script manually.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    <div class='quotetop'>QUOTE </div>

    --- Quote Start ---

    I can&#39;t log directly to disk, as I am capturing 16-bit samples at 50 Msps. So what I was planning to do was log 10 seconds (~1 gig) worth of data to DRAM using DMA from our custom logic, and then spend 20 minutes or so writing this to a disk using FTP.[/b]

    --- Quote End ---

    Since you need a fast access to DDR it would probably be a better solution not to connect it to the Avalon bus, but to use the other interface offered by the Altera DDR IP.

    Than create a sopc builder component that can be used for Nios read access to the DDR and has a bypass DMA used for high speed write transfers to the DDR.

    As far as I understand it, you still have some other memory chip on the board that can be used for running Linux.

    This is not really an easy solution but it might be a good one.

    IzI
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    Thanks for the tips hippo.

    I disabled the address range check in SOPC, and then ran the generate script manually. It compiled fine. I then compiled a new kernel, but this is not booting. The download suceeds, but then the system hangs.

    I have set my DDR SDRAM start address to be 0x4000000, since when I put in the 1GB DIMM, it will need to be there. This is since according to SOPC builder, the RAM has to be at an offset that is a multiple of its size. (Is this true?)

    So my memory map looks like:

    0x00000000-0x00002FFF: Peripherals, ie DMA controller, PIOs, timers. Includes EPCS controller, JTAG debug module.

    0x40000000-0x4FFFFFFF: DDR SDRAM, 256MB. (When I put in the 1 GB DIMM, this will end at 0x7FFFFFFF.)

    So the kernel is being downloaded at 0x40500000, but it will not execute from there. So, is the limitation also that the executable code must be in the *first* 256MB? If so, how do I reconcile this with the fact that the memory needs to be at an offset that is a multiple of its size?

    I would be fine with losing some memory capacity and overlaying the DDR RAM starting from 0x00000000, but I don&#39;t think this is possible.

    Iztok.jeras: I don&#39;t have another memory on the board that uClinux can run from, that is why I am trying to run out of the DDR SDRAM.

    Regards,

    Josh
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    do the trick, (though I haven&#39;t tried myself)

    you have to change the boot loader,

    because normal "call" can not work across 256M boundary, you need to use "callr" or "jmp" to jump start from flash to sdram.

    check nios2 manuals on these instructions.