1 2 Previous Next 21 Replies Latest reply: Jun 5, 2010 10:40 AM by hoffman RSS

sccAPI lib and docs

rishikhan Community Member
Currently Being Moderated

Do you know where I can find the sccAPI lib? and any docs to use it? 
I'd like to know how to link an app so that when the core is reset, it runs the right program, how to setup the LUTS, etc.

My goal is to build and run an OS image that is not linux and runs in the same type of mode that linux is run.


  • 1. Re: sccAPI lib and docs
    BOBNO123 Community Member
    Currently Being Moderated

    Working on it.  We weren't planning to provide these initially, but if demand is there, we will get it.  We will put sources on your MCPC when it is ready.  Documentation will be sparse right now.

     

    Bob Noradki

    SCC Team

  • 2. Re: sccAPI lib and docs
    jheld Community Member
    Currently Being Moderated

    You don't have to write your own program to load something other than Linux.

    Do you aleady know how to build and load a bare metal binary with sccGui?

  • 3. Re: sccAPI lib and docs
    rishikhan Community Member
    Currently Being Moderated

    No, I don't know how to build and run a bareMetal app. Can you point me to some docs?

    Also, eventually, we will want to be communicating between the frontend and the sccChip later. We need some kind of mechanism to talk across the PCI. Do you have any suggestions for that?

  • 4. Re: sccAPI lib and docs
    jheld Community Member
    Currently Being Moderated

    First thing to do is to take the loadmap and binary of the code(s) (must include boot code etc) that you want to load onto core(s) and turn it into an ASCI format using the bin2obj tool.

     

    Two more pieces of information must be defined to run your code on SCC, what to run on which cores, and how to initially configure the memory mappings (LUTs).   The .mt file must be created that describes the placement of the image on cores.   It is used with a sccMerge script to create a single image and a table of LUT values for loading.

    For example, to start hello.32.obj on core 0x00, core 0xYY and core 0xZZ you need to create an mt file (hello.mt) with the following content:

    # pid [white-space] object file

    0x00 <obj-path>/hello.32.obj

    0xYY <obj-path>/hello.32.obj

    0xZZ <obj-path>/hello.32.obj

    You may also mix different objects (e.g. hello.32.obj and pingpong.32.obj) on different cores.

    The .obj and the .mt are fed to the sccMerge perlscript which merges the object files into one combined image for loading and creates a configuration file for the memory LUTs.  For example, given our hello example to put it the system with 4MB assigned to each core and with 12 cores per memory controller you would invoke sccMerge (objMerge):

    sccMerge –noimage –m 4 -n 12 –force <mt-path>/hello.mt

    Invoke sccMerge with the –h option for a listing of the options.

    The merge tool will create an “obj” folder with “mch_0_0.obj” and “lut_init.dat”. These are the files you need to load from sccGui. Use the following flow:

    ·        Invoke the reset (wiper symbol)

    ·        Pre-Load the object file

    ·        Pre-Load the LUT file

    ·        (Optionally enable/disable L2 cache)

    ·        Release the resets with the reset dialog

    Which is basically working through the sccGui tools menu from top to bottom. You can use the memory reader widget to see if the code (that should modify some specific memory location) executed.

     

     

    After executing sccMerge you can also use command-line tools to preload your image and release the resets:

    ·        sccBoot –g <obj-path>

    ·        sccReset –r <list or range of cores where the reset should be released>

    ·        Then you can use sccDump to check the results (if your BMC application modified a memory location).

     

     

    I'd encourage you to explore the tools other than sccGui that are in /opt/sccKit/current/bin by using the -h switch with them. 

  • 5. Re: sccAPI lib and docs
    hoffman Community Member
    Currently Being Moderated

    that sounds pretty straightforward. where does one specify the start address for the 16 bit

    segmented code? it doesn't seem to be represented in the .obj file

  • 6. Re: sccAPI lib and docs
    rishikhan Community Member
    Currently Being Moderated

    Another way to state Eric's question is:

    In a bareMetal app, how do we go from SystemReset to main()?

     

    For example, say I had the following program in main.c:

    char buf[100] = "";

    int main(int argc, char **argv)

    {

      char internal_buf[100] = "Hello";

      int i = 0;

      while(internal_buf[i] != 0)

      {

        buf[i] = internal_buf[i];

        i++;

      }

      return 0;

    }

     

    How would I go about making an obj file that can fit into the workflow that you described above?

  • 7. Re: sccAPI lib and docs
    jheld Community Member
    Currently Being Moderated

    "Bare metal" means really bare! 

     

    The processor boots in real mode starting 16bytes below the top of physical memory.  A bare metal app needs to take it from there.

    See section 16.1 of the P54CPentium processor manual in the docs (and on www.intel.com/info/scc) for details.

     

    We have nothing like a BIOS on SCC, though we're looking into the possibility, but for now the sccKit on the MCPC serves some of that role,

    setting up memory mappings (LUTs) and loading memory as directed.  The rest of boot would be statically bound into the image loaded.

     

    Your program below would only run after a lot has happened and presumes c runtime libs etc.  That's why we have the Linux version, for all those not interested in OS/embedded app level coding.

  • 8. Re: sccAPI lib and docs
    rishikhan Community Member
    Currently Being Moderated

    Thanks Jim,

      "The processor boots in real mode starting 16bytes below the top of physical memory. " is what we were looking for.

  • 9. Re: sccAPI lib and docs
    hoffman Community Member
    Currently Being Moderated

    i've tried to follow your recipie, using sccMerge to construct an obj directory

    which i then pass to sccBoot -g

     

    the mch image matches the lut target for the pre-translation obj address, so

    sccMerge is doing the mapping correctly

     

    however, after sccBoot, sccDump -c 0 doesn't match the lut configuration in

    lut_init.dat, or lut_init.vi

     

    further the contents of mch_0_0 dont match the output of sccDump -d 0 at the

    specified address

     

    i know this isn't enough information for you to help, so i guess i have a couple

    questions if you could answer them.

     

    - the 'my tile id' register output for sccDump - c 0 shows '5', for sccDump -c 5 it shows 2d.

       the format of this isn't discussed in the EAS, but i assume this is ok?

     

    - i would expect that even if nothing else was working, if mch_0_0.obj

       shows data at /origin 1bd3f0000, then after a successful run of sccBoot, i should

       be able to use sccDump -d 0 1bd3f0000 to verify the contents?

     

    - can you think of any reason why the lut tables wouldn't be updated?

     

    hoffman@marc001:~$ sccBoot -g obj
    INFO: Welcome to sccBoot 1.1.1 (build date May 19 2010 - 16:22:25)...
    INFO: Pulling reset of all cores...
    INFO: Preloading Memory with object file...
    INFO: Found object for MC x=0, y=0: "obj/mch_0_0.32.obj"...
    INFO: writeMemFromOBJ(...): Configuration of memory done!
    INFO: Successfully (re-)loaded object file "obj/mch_0_0.32.obj"...
    INFO: Preloading LUTs...
    INFO: Configuring LUTs with content of file "obj/lut_init.dat"...
    INFO: -> Configuration of LUTs done!
    INFO: Image is now pre-loaded. Release resets to start individual cores...
    hoffman@marc001:~$

     

    thanks for any assistance you can give

  • 10. Re: sccAPI lib and docs
    hoffman Community Member
    Currently Being Moderated

    an update on status, i'm currently stuck with the board in a bad state. neither

    the gui nor the sccBmc commands complete, both complaining that they

    cant connect to the bmc server at .245 to train the sif

     

    however, before that happened i ran some experiments, so things are partially sane:

     

       - changing the obj target address to 0 results in my data showing up at sccDump -d 0 0,

         but i cant seem to write to any other offset in the same 16M block, or any other block.

         i suspect there is an additional layer of memory address translation that i'm just not

         aware of

     

      - i've been able to change the luts in lut_init.dat and see them show up in sccDump -c after

        an scc boot. i could swear that earlier lut_init.dat was pointing to 0,5 east and sccdump was

        pointing to 0,0 west....but lets just assume i was deluded

     

       - i believe that the mapping being set up by sccMerge is over 8G in the 0,0 mch,

         (local offset 3f4) which could explain some issues if the upper bits aren't ignored in the

         memory controller [thus your suggestion about using -m 4 above, which i ignored]

  • 11. Re: sccAPI lib and docs
    jheld Community Member
    Currently Being Moderated

    "- the 'my tile id' register output for sccDump - c 0 shows '5', for sccDump -c 5 it shows 2d.

       the format of this isn't discussed in the EAS, but i assume this is ok?"

     

    Yes it is.  The tileid is 11 bits. Top 4 bits are Y, next 4 bits are X coordinate, bottom 3 bits are the the requesting agent - in this case 0x5 which is the SIF which is true given you are using the MCPC over the SIF.

     

    "- i would expect that even if nothing else was working, if mch_0_0.obj

       shows data at /origin 1bd3f0000, then after a successful run of sccBoot, i should

       be able to use sccDump -d 0 1bd3f0000 to verify the contents?"

    Not sure why not, but do you really have 8GB on each MC? (a 32GB configuration?)

  • 12. Re: sccAPI lib and docs
    hoffman Community Member
    Currently Being Moderated

    yes, this is in the programmers guide page 24

     

    thank you

  • 13. Re: sccAPI lib and docs
    jheld Community Member
    Currently Being Moderated

    I was using -m 4 because I'm accustomed to a 16GB machine.

    Not sure what you mean by offset 3f4.

     

      - changing the obj target address to 0 results in my data showing up at sccDump -d 0 0,

         but i cant seem to write to any other offset in the same 16M block, or any other block.

         i suspect there is an additional layer of memory address translation that i'm just not

         aware of

    When loading memory and sccDumping memory system addresses are used that don't involve any further translations.

    When you say that you can't write in locations other than 0, I presume you mean load those locations with sccBoot? 

     

    Have you tried examining the linux.obj, etc as examples?  You can use sccGui to explore what memory image looks like in the file and then using the memory widget to examine memory locations.

  • 14. Re: sccAPI lib and docs
    hoffman Community Member
    Currently Being Moderated

    thanks for your suggestions. its very likely that i was struggling with mappings

    constructed by sccMerge for a larger machine

     

    the linux image doesn't seem to be constrained as to the alignment and size of the

    segments that its writing, but if i change the mch_0_0.obj offset to be nonzero, then

    i can no longer read back the bytes written by sccBoot with sccDump

     

    linux boots quite consistently, so i'm just missing something

     

    i'll post a more concrete example once the board is running again

     

    thanks for your help

1 2 Previous Next

More Like This

  • Retrieving data ...