1 2 Previous Next 15 Replies Latest reply: May 16, 2012 3:45 AM by JanArneSobania RSS

The new SCC Linux modifications

Nil Community Member
Currently Being Moderated

Hi,

 

I would like to use Inter-core interrupt and process notifying code posted in http://communities.intel.com/thread/18234?tstart=0. Since new sccLinux for sccKit1.4.2 the tree has changed so much and i am lost how to apply patch.  Table below lists the changes made by patch. I am unable to locate many files which is modified in new tree.

 

Any help or point in direction will be appriciated.

 

Thank you.

 

 

Files ModifiedFiles Added
linuxkernel/initramfs/rck_devices.list
linuxkernel/linux-2.6.16-mcemu/.config.RCK
linuxkernel/linux-2.6.16-mcemu/drivers/char/rckmem.c
linuxkernel/linux-2.6.16-mcemu/drivers/net/rckmb.c
rckos/bin/rck_devices.list
rckos/async-scc/Makefile
rckos/async-scc/async-scc.c
rckos/async-scc/irq.c
rckos/async-scc/mpb.c
  • 1. Re: The new SCC Linux modifications
    mwaughex Community Member
    Currently Being Moderated

    Nil,

    Are you still working on this?

    Ted and I had tested the patch with the old build.  Not with 1.4.2.

    I believe Merijn Verstraaten created the patch.  Jan-Arne is active in maintaining the new linux.

  • 2. Re: The new SCC Linux modifications
    Nil Community Member
    Currently Being Moderated

    Hi,

     

    Yes I am still working on this. Is it possible for Jan-Arne to guide me which file I need to modify in order to make this patch work. I had tried doing it but as it seems the file and function name in new Linux tree has changed considerable (i was unable to find the file names that I need to change in "buildroot-2011.11-scc.patch").

     

     

    Thank you.

  • 3. Re: The new SCC Linux modifications
    JanArneSobania Community Member
    Currently Being Moderated

    Hi,

     

    we are no longer using the "rck" name prefix, all names start with "scc" now. So you should be able to find all files in the same folder, but with the new name (and internal functions renamed accordingly). The only exception to this renaming concerns exposed device names like "/dev/rckmem". For backwards compatibility with existing user-mode code, these names stay the same.

     

    Another important change is that, for kernel code, certain low-level features like triggering the interrupt bits in core's configuration registers have been removed from individual drivers and relocated to the new sccsys ("SCC System Driver"). Such bit manipulations are now protected by the respective LOCK bits, so multiple cores sending interrupts at the same time to the same destination should no longer be able to interfere. You can revert to the old (unprotected) behaviour by using a module parameter for sccsys.

     

    Regards,

    Jan-Arne

  • 4. Re: The new SCC Linux modifications
    Nil Community Member
    Currently Being Moderated

    JanArneSobania wrote:

     

    Another important change is that, for kernel code, certain low-level features like triggering the interrupt bits in core's configuration registers have been removed from individual drivers and relocated to the new sccsys ("SCC System Driver"). Such bit manipulations are now protected by the respective LOCK bits, so multiple cores sending interrupts at the same time to the same destination should no longer be able to interfere. You can revert to the old (unprotected) behaviour by using a module parameter for sccsys.

     

    Regards,

    Jan-Arne

     

     

    Thank you for quick reply. is there any documentation or something where I can get more info for sccsys as I am not too familiar with it.

  • 5. Re: The new SCC Linux modifications
    JanArneSobania Community Member
    Currently Being Moderated

    There is no documentation besides the comments in the source and header files. But I tried to be extensive... And in case you need help, please feel free to send me a mail or PM.

  • 6. Re: The new SCC Linux modifications
    Nil Community Member
    Currently Being Moderated

    Hi,

     

    Out of 5 files i am still unable to find 3 files in new linux tree.

     

     

    linuxkernel/initramfs/rck_devices.list
    linuxkernel/linux-2.6.16-mcemu/.config.RCK
    rckos/bin/rck_devices.list

     

    It will be helpfull if you can shed some light on this.

     

    Thank you.

  • 7. Re: The new SCC Linux modifications
    JanArneSobania Community Member
    Currently Being Moderated

    Hi,

     

    if I remember correctly, .config.RCK is the kernel configuration file of the old build system. We are using buildroot instead of the old system now, so any changes to the kernel configuration need to be integrated therein. I recommend you issue "make linux-menuconfig" in the buildroot folder and change configuration variables manually. The default kernel configuration should already include support for loadable modules, so it is possible that you do not need to change anything...

     

    Unfortunately I didn't find a location in the patch you linked that modifies rck_devices.list. Is there another version of the patch? Or which modifications were needed with the old Linux? I think these files for creating files under /dev/ manually, but this should no longer be necessary with the new Linux. Just create a misc device (see sccmem.c for an example); it should appear automatically under /dev/, as long as the init script mounts devtmpfs.

     

    Regards,

    Jan-Arne

  • 8. Re: The new SCC Linux modifications
    Nil Community Member
    Currently Being Moderated

    Hi,

     

    sorry I forgot to mention about new version of patch. I have attached new version of patch now. If possible can you please have a look at it. Another thing I am finding is that some of the functionality exists in file (particularly in sccmem.c) and some of it is not so I am bit confused as how much I need to change it or there is nothing to change at all?

     

    Any suggestion will be helpful.

     

    P.S there is no command "make linux-menuconfig" when i issue command it says "no rule to make target..."

     

    Thank you.

     

    Regards,

    Nil

  • 9. Re: The new SCC Linux modifications
    JanArneSobania Community Member
    Currently Being Moderated

    Hi,

     

    thank you, I see the issue now. The patch file includes at least three different patches:

     

    1) The final fix for the L2 cache flush that is discussed in Bug #195. You do not need to incorporate these patches that effect scc*_write (without rckdyn_write), they should already be included.

     

    2) A patch to sccmpb_mmap that enables the PWT bit when mapping pages as MPBT. This makes sense to me (there is no alternative way to flush these mappings apart from a full L2$ flush), but nevertheless I have never seen this patch before. It is also not present in sccKit 1.4.2, but it is general enough that we should consider incorporating it, even in the base distribution. Was there a discussion about this issue that I missed? For reference, here is the corresponding part of the diff file:

     

    @@ -162,7 +187,7 @@
       PRINTD(KERN_DEBUG "             VM Start: 0x%08lx, size: 0x%08lx, offset: 0x%08lx\n", (unsigned long) vma->vm_start, (unsigned long) size, (unsigned long) vma->vm_pgoff);
     
       /* Mark the page protection value as "cacheable" MPB type */
    -  vma->vm_page_prot = __pgprot((pgprot_val(vma->vm_page_prot) & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_MPE);
    +  vma->vm_page_prot = __pgprot((pgprot_val(vma->vm_page_prot) & ~(_PAGE_PCD ))| _PAGE_PWT | _PAGE_MPE);
       PRINTD(KERN_DEBUG "             VM pgprot value is 0x%02lx!\n", pgprot_val(vma->vm_page_prot));
     
       /* Make sure that the OS doesn't modify the allocated pages... */

     

    3) The "meat" of the patch for creating the rckdyn devices. Unfortunately this code relies on the old cdev structure, which I do not recommend to use due to it referring to pre-defined major and minor function names. I recommend you use misc_devices instead; as examples, you can refer to how the "rckmpb" and other devices in sccmem.c are created now. There should also be some kind of module-reserved field in that structure you could use to tell rckdyn_mmap which flags you want to have on your mapping (in the patch file, it uses the minor function number, which will no longer work with misc devices as they are not guaranteed to be continuous).

     

    What was your current directory when you invoked "make linux-menuconfig"? It works for me if invoked directly from the buildroot-2011.11 directory:

     

    linuxbuild@scc:~/Desktop/sccLinux/buildroot-2011.11$ make linux-menuconfig

     

    When trying this a minute ago, I actually got an error about missing ncurses. This command seems to depend on certain environment variables that may be changed by other scripts (I suspect icc). So I recommend you open a fresh shell for it...

     

    Regards,

    Jan-Arne

  • 10. Re: The new SCC Linux modifications
    Nil Community Member
    Currently Being Moderated

    1) If I understood correctly I just need to add  rckdyn_write
         and related functions.

     

    2) There was no discussion about this that i am aware of.

     

    3) Sorry but I am still bit confused about this part
         "There should also be some kind of module-reserved
         field in that structure you could use to tell
         rckdyn_mmap which flags you want to have on your
         mapping (in the patch file, it uses the minor
         function number, which will no longer work
         with misc devices as they are not guaranteed
         to be continuous).".
        
         i will come back to you when I have more concrete question.

     


    "make linux-menuconfig" works it was my mistake .

     


    Thank you for all your help.

     

    Regards,

     

    Nil

  • 11. Re: The new SCC Linux modifications
    JanArneSobania Community Member
    Currently Being Moderated

    1) If I understood correctly I just need to add  rckdyn_write
         and related functions.

    Yes, that should be sufficient. But I would also add the patch for /dev/rckmpb's mmap, just to be safe.

     

    3) Sorry but I am still bit confused about this part

         "There should also be some kind of module-reserved
         field in that structure you could use to tell
         rckdyn_mmap which flags you want to have on your
         mapping (in the patch file, it uses the minor
         function number, which will no longer work
         with misc devices as they are not guaranteed
         to be continuous).".
        
         i will come back to you when I have more concrete question.

     

    I meant the following code from rckdyn_mmap:

     

    +/* Character device mmap method for dynamic memory type devices */
    +static int rckdyn_mmap(struct file *filp, struct vm_area_struct *vma) 
    +{
    +  int minor = iminor(filp->f_dentry->d_inode);
    +  int major = imajor(filp->f_dentry->d_inode);
    +  size_t size = vma->vm_end - vma->vm_start;
    +  int dyndev_number = minor - DYNDEV_MINOR_START;
    [...]
    +  dyndev_number & 0x1 ? flagmask |= _PAGE_MPE : flagnegmask & ~_PAGE_MPE;
    +  dyndev_number & 0x2 ? flagmask |= _PAGE_PWT : flagnegmask & ~_PAGE_PWT;
    +  dyndev_number & 0x4 ? flagmask |= _PAGE_PCD : flagnegmask & ~_PAGE_PCD;
    [...]
    +  vma->vm_page_prot = __pgprot((pgprot_val(vma->vm_page_prot) & flagnegmask)| flagmask);

     

    It uses the device's minor number to calculate the offset (dyndev_number) within the rckdyn devices. This offset, in the range 0 to 7, is used later to set the page table flags for the mapping (MPE, PWT, PCD). So for /dev/rckdyn000, minor DYNDEV_MINOR_START+0, all flags are zero. For /dev/rckdyn001, minor DYNDEV_MINOR_START+1, its MPE=1, PWT=PCD=0 and so on.

     

    You cannot reuse this code as-is if you are using miscdevices, because there will be no dedicated starting minor number for them. You need to pass in the dyndev_number another way. I had hoped there was a field in "struct miscdevice" you could use, but I just looked at the definition and it seems there is not. So instead, you could define your own structure that carries this information, and also includes a field of type "struct miscdevice". It is already necessary to allocate space for a miscdevice yourself, so this additional structure should be quite simple to implement.

     

    Please also note that the above code contains a subtle error: flagmask is manipulated using "|=", which is an assignment. However, flagnegmask is left unchanged, due to "&" not having any side effects here; therefore, all "otherwise" expressions (after the ":" of each "?" operator) do not do anything meaningful, and an optimizing gcc can and will remove them completely. I doubt this behaviour is expected; it results in "... & flagnegmask" never clearing any flag, so whatever is already set in vm_page_prot upon entry of rckdyn_mmap will also be set afterwards.

     

    Regards,

    Jan-Arne

  • 12. Re: The new SCC Linux modifications
    Nil Community Member
    Currently Being Moderated

    I was reading up on misc devices and i found at http://www.linuxjournal.com/article/2920  "The real question with the misc device driver is “what is a sensible value for the minor field?” Assignment of minor numbers is performed in two ways: either you can use an “officially assigned” number, or you can resort to dynamic assignment. In the latter case, your driver asks for a free minor number, and the kernel returns one."

     

    So my question, Is it possible to set minor number manually like

     

    #define NUM_DYNDEV 8

                    #define DYNDEV_MINOR_START 3

                    static struct miscdevice rckdyn_cdev[NUM_DYNDEV];

                    static int rckdyn_mmap(struct file *filp, struct vm_area_struct *vma);

     

                    ...

     

    for(i = 0; i < NUM_DYNDEV; i++)
        {
            /* First set the file ops struct */
            rckdyn_fops[i].open = sccmem_open;
            rckdyn_fops[i].release = sccmem_release;
            rckdyn_fops[i].mmap = rckdyn_mmap;
            rckdyn_fops[i].write = rckdyn_write;
            rckdyn_fops[i].owner = THIS_MODULE;
           
            rckdyn_cdev[i].fops = &sccdcm_fops[i];
            rckdyn_cdev[i].minor = DYNDEV_MINOR_START + i;
            //rckdyn_cdev[i].name = rckdyn + ; /*convert "i" to three digit binary to assign proper name like rckdyn000, rckdyn001 ...*/

    ...
           }

     

    I have left the name unchange for time being (rckdyn_cdev)

     

    Regards,

    Nil

  • 13. Re: The new SCC Linux modifications
    JanArneSobania Community Member
    Currently Being Moderated

    I think it is possible to statically assign minor numbers, especially in an environment like sccLinux where we don't need interoperability with arbitrary other drivers. But as the article you linked to says, doing so is not recommended, as it can break if another modules chose the same minor number.

     

    Regards,

    Jan-Arne

  • 14. Re: The new SCC Linux modifications
    Nil Community Member
    Currently Being Moderated

    Hi,

     

    Is there any particular reason why the misc devices are used instead of cdev?

     

    another thing is that I am getting error when trying to compile the Linux in sccmem.c

     

    In function 'rckdyn_write'

    " error: '__PHYSICAL_START' undeclared (first use in this function) "

     

    Any suggestion?

     

    Regards,

    Nil

1 2 Previous Next

More Like This

  • Retrieving data ...

Legend

  • Correct Answers - 4 points
  • Helpful Answers - 2 points