1 2 Previous Next 21 Replies Latest reply on Jun 5, 2010 10:40 AM by hoffman Go to original post
      • 15. Re: sccAPI lib and docs

        The format of the tileID is described on page 11 of the EAS (June 2 version). However, this discussion is about the tileID in the system address. The implication is that this same format is true for the TileID register, but that's not explicitly stated. The tileID format can be confusing because it is not continuous.

        • 16. Re: sccAPI lib and docs

          my mch_0_0.32.obj looks like:


          /origin 0
          /origin 00000000
          /origin fd3f0000
          00000000 00000000 0000ffff 00cf9a00
          0000ffff 00cf9200 00000017 d231ffff
          d28e10b2 c28eda8e ea8ee28e 001000bc
          0000a100 a3400000 00000000 deeb090f
          00000000 00000000 00000000 00000000



          and after sccBoot -g obj, my sccDump output looks like:


          hoffman@marc001:~$ sccDump -d 0 0xfd3f0000 16
          INFO: Packet tracing is disabled...
          INFO: Opened "/tmp/sccKit_hoffman/trace.log" for writing...
          INFO: openBMCConnection(): You are participant #1
          INFO: Initializing System Interface (SCEMI setup)....
          INFO: The selected linkfile is: "/opt/sccKit/1.1.1/resources/transactor.link"...
          INFO: Successfully connected to PCIe driver...
          INFO: Welcome to sccDump 1.1.1 (build date May 19 2010 - 16:24:34)...
          INFO:  Contacting SystemIF to read memory. Please be patient ...
          INFO:  done System Read.
          INFO: --------------------------------------------------
            Reading on sub-id6 of Tile 0x0
            startAddress = fd3f0000 hex (4248764416 dec) 16 bytes.
            stopAddress  = fd3f0010 hex
            lastAddress  = fd3f000f hex
                 Length  = 32 bytes
          INFO: --------------------------------------------------
          INFO: ** 8 bits alignment
          INFO: --------------------------------------------------
          00000000fd3f0000 | 80 00 60 00 00 10 00 00  | ..`.....
          00000000fd3f0008 | 02 00 10 80 00 00 40 00  | ......@.
          00000000fd3f0010 | 40 00 01 00 02 00 10 10  | @.......
          00000000fd3f0018 | 80 00 02 00 20 08 12 c0  | .... ...


          however, if i change the origin to 0, and rerun sccBoot, then the results returned by sccDump -d 0 0 16

          change to match my gdt contents from the image

          • 17. Re: sccAPI lib and docs

            so i've been able to boot a little test thing by:


              building a source .obj which is 16MB, with an /origin of 0


              putting the initial jump 16 bytes from the top


              editting the lut_init.dat to point the 0xff region at 0 on mch_0_0


              running sccBoot, and sccReset. the image looks sane and i get a rolling counter. great.


            if i try to do it without mucking with things:


              my original /origin is at ffff0000 (i want to just load one segment at -64k)


              scc merge has a lut entry at ff of 18f4, which looks like 0_0, f4000000


              the mch_0_0.32.obj  origin for my segment is listed at fd3f0000


              after scc boot i dont see my data at f4000000 or fd3f0000


            i'm clearly just not understanding the model here.


              i'm thinking that the object provided by the .mt file has an address inside the lut translation,

              and sccmerge is responsible for translating that into a memory bank offset after deciding

              on a lut configuration


              if so then why do the lut addresses andthe mch_0_0.32.dat addreses differ in the high bits


              and of course, still, what is preventing me from seeing the loaded data if i dont load it at zero


            if its clear that i'm operating in a fantasy world, or you could suggest another experiment, that would

            be great. thanks much

            • 18. Re: sccAPI lib and docs

              Hi, the “origin” in the object file holds a word address while sccDump wants a byte address. I guess that's the reason for not seeing the expected data. So you need to shift the address of the origin entry to the left before passing the address to sccDump. Please give it a try and let me know if it works. Thanks...

              • 19. Re: sccAPI lib and docs

                i was thinking it might be something like that, but the bits didnt match. what is word size

                used in /origin? (the shift offset)



                • 20. Re: sccAPI lib and docs

                  Word size on IA is 32b, 4bytes.  So you should multiple the origin value by 4

                  Remember to use 0x prefix for sccDump - it presumes decimal while the origin value is in hex.

                  • 21. Re: sccAPI lib and docs

                    sorry, i neglected to write back. yes, everything works exactly as you might think. the problem was that

                    having the origin shifted up by two left me with a different lut target entirely.


                    if i /origin the per-merge object at at 0x3fffc000, my little test boot is mapped and runs


                    thanks for your (collective) help

                    1 2 Previous Next