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

    sccAPI lib and docs

    rishikhan

      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

          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

            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

              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

                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

                  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

                    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

                      "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

                        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

                          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

                            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

                              "- 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

                                yes, this is in the programmers guide page 24

                                 

                                thank you

                                • 13. Re: sccAPI lib and docs
                                  jheld

                                  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

                                    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