1 2 Previous Next 21 Replies Latest reply: Jun 5, 2010 10:40 AM by hoffman Go to original post RSS
  • 15. Re: sccAPI lib and docs
    tedk Community Member
    Currently Being Moderated

    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
    hoffman Community Member
    Currently Being Moderated

    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
    hoffman Community Member
    Currently Being Moderated

    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
    michael.riepen Community Member
    Currently Being Moderated

    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
    hoffman Community Member
    Currently Being Moderated

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

    used in /origin? (the shift offset)

     

    thanks

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

    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
    hoffman Community Member
    Currently Being Moderated

    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

More Like This

  • Retrieving data ...