Menu ▾ ▴

#2 Request ICS9LPRS355BKL

open
nobody
pll (2)
5
2013-02-28
2013-02-17
Sasyn
No

Hi, I would like to request the addition of the Integrated Circuit Systems 9LPRS355BKL, datasheet at link

This is for an HP Compaq 2710P, for which there is some interest at notebookreview.com (forum.notebookreview.com) though there are no solutions for linux, and hardware modding or bios flashing are the only currently working techniques. (The bios solutions are dated and not maintained, whilst the hardware mod descriptions are confused and provide no photographs).

I have looked at some of the other PLL data files available for lfsb, with a view to attempting to write on myself, but other than a list of basic clock multipliers I can't tell what data is required from the datasheet or how to assemble it.

Thanks for any work or advice you can provide.

1 Attachments
9LPRS355.pdf

Discussion

  • Nick Kislitsa

    Nick Kislitsa - 2013-02-18

    Contact me per email. I'll need i2cdump data to start.
    What's with the TME lock? That's the big problem.

     

  • Sasyn

    Sasyn - 2013-02-18

    Apologies, I thought the 2510p group had disabled TME lock for this chip in software but it turns out a hardware mod is needed for both. Will email if I have any luck with the TME lock.

     

  • Nick Kislitsa

    Nick Kislitsa - 2013-02-19

    There is a workaround for TME with swaping clock source PLL1 to PLL3.
    It's worth to try before doing hw mod.

     

  • Sasyn

    Sasyn - 2013-02-19

    I don't seem to have an email address to contact you on. Thanks for spotting the non-hardware mod. I am now having problems enabling the SMBus. I2C is enabled, but SMBus does not show as a device.

    i2cdetect -l gives:

    i2c-0 unknown i915 gmbus disabled N/A
    i2c-1 unknown i915 gmbus ssc N/A
    i2c-2 unknown i915 GPIOB N/A
    i2c-3 unknown i915 gmbus vga N/A
    i2c-4 unknown i915 GPIOA N/A
    i2c-5 unknown i915 gmbus panel N/A
    i2c-6 unknown i915 GPIOC N/A
    i2c-7 unknown i915 gmbus dpc N/A
    i2c-8 unknown i915 GPIOD N/A
    i2c-9 unknown i915 gmbus dpb N/A
    i2c-10 unknown i915 GPIOE N/A
    i2c-11 unknown i915 gmbus reserved N/A
    i2c-12 unknown i915 gmbus dpd N/A
    i2c-13 unknown i915 GPIOF N/A

    I have tried the boot options:

    clocksource=acpi_pm
    acpi_enforce_resources=lax
    clocksource=hpet (separately from acpi_pm)

    but with no effect. I have read that SMBus should appear as i2c-14. I assume it is disabled in the Function Disable register, as described in post #4

    Unfortunately, I need to work out its address relative to the Root Complex Base Address, and when I query this by "setpci -s 0:1f.0 f0.l" (used for the 2510p with the same chip) the result is 'ffffffff'. Do you have any ideas on retrieving the true value?

    On a side note, post #10 and others mention modifications to lsfb for ICS9LPRS355 not found on either of the project's pages which may be interesting if you haven't already seen them.

     

  • Nick Kislitsa

    Nick Kislitsa - 2013-02-19

    Email is in the sources.
    I'll investigate how to unhide smbus.

    I found some ICS9LPRS355 code with static register values. I'll write N/M calculation. But that is not that important if static code works.

     

  • Nick Kislitsa

    Nick Kislitsa - 2013-02-25

    Can't help to unhide smbus without the hardware to hack with.
    Tried the unhide_ICH_SMBus script from lm-sensors?

     

  • Sasyn

    Sasyn - 2013-02-26

    I had tried the lm-sensors script but it only works with ICH 4 and older.

    I was successful unhiding the SMBus, it had to be enabled in the function-disable register. Not sure why the setpci command was wrong but I was able to use BAR-edit to find the actual RCBA, 0xfed90001. Also needed to modprobe i2c-i801. Presently, a grub commandline "write_dword 0xfed93418 033c0005" is needed, but I may try to get a kernel patch submitted.

    I'm now trying to use the modified code (post #10 linked above) but it always tries to access i2c-0 rather than i2c-14, and I get the error

    "Can't change frequency, SetFSB error: Cannot allocate memory"
    I just can't figure out where this is specified.
    i2cdump (if still wanted) is:

         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 31 85 fc 77 ff f0 30 11 d0 65 7d 00 0d             1??w.?0??e}.?
     

    Last edit: Sasyn 2013-02-26

    • Nick Kislitsa

      Nick Kislitsa - 2013-02-26

      Ok.
      Will write the pll code with the TME workaround.
      And add option to lfsb executable to force i2c-dev index.

       

    • Nick Kislitsa

      Nick Kislitsa - 2013-02-27

      I can't guess the formula for the frequency.
      Should be like this: Frequency = 24 x Ndiv(9:0)/Mdiv(5:0)
      Can you try the static code? I'll try to calculate formula using its table data.
      i2c device forcing code is in git repo.

       

      • Sasyn

        Sasyn - 2013-02-27

        lfsb.c:(.text+0x48): undefined reference to `clock_gettime'
        -lrt needs to be added to line 18 of /src/makefile after the project files.

        sudo lfsb -d 14 ics9lprs355 133
CPU governor 'performance' set.
CPU frequency : 1197.03 MHz (estimated)       ##now detected correctly
PLL ics9lprs355 is supported (untested)
*** stack smashing detected ***: lfsb terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f83cbe39807]lfsb[0x40472a]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7f83cbe397d0]lfsb[0x400e6b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f83cbd5076d]lfsb[0x40107d]

        Seems to be a problem with devname, i2c.c, line 35

         

        Last edit: Sasyn 2013-02-27

  • Nick Kislitsa

    Nick Kislitsa - 2013-02-27

    Please try code in git repo. I have added TME workaround and fsb set functions.
    First try to get FSB only: lfsb -d 14 ics9lprs355
    If it's calculated right, then try to change it. The N/M formula is just a guess.

     

    • Sasyn

      Sasyn - 2013-02-27

      Still the same as my last reply, same crash, still needs -lrt in makefile.

      sudo lfsb -d 14 ics9lprs355
CPU governor 'performance' set.

CPU frequency : 1197.02 MHz (estimated)
PLL ics9lprs355 is supported (untested)
*** stack smashing detected ***: lfsb terminated
       

      Last edit: Sasyn 2013-02-27

      • Nick Kislitsa

        Nick Kislitsa - 2013-02-27

        Send executable to my email.
        Try make it with make debug maybe there will be more information.

         

        • Sasyn

          Sasyn - 2013-02-27

          sudo lfsb -d 14 ics9lprs355
          CPU governor 'performance' set.

          debug output:

          CPU frequency : 1197.03 MHz (estimated)
PLL ics9lprs355 is supported (untested)
DEBUG: Using device '/dev/i2c-14'
unhide DEBUG: 32 bytes read : 31 85 FC 77 FF F0 30 11 D0 65 7D 00 20 CF 44 EF 2F A0 8F F2 23 00 CE 61 53 D8 75 05 C2 00 AD CA 
CheckTME DEBUG: 32 bytes read : 31 85 FC 77 FF F0 30 11 D0 65 7D 00 20 CF 44 EF 2F A0 8F F2 23 00 CE 61 53 D8 75 05 C2 00 AD CA 
*** stack smashing detected ***: lfsb terminated

          will send executable.

           

          • Nick Kislitsa

            Nick Kislitsa - 2013-02-27

            I'm stupid. Midnight coding kills brain.
            Wrong buff size.
            Checkout repo.

             

            • Sasyn

              Sasyn - 2013-02-27

              EDIT: it no longer crashes, but reports the TME is locked and doesn't manage to change the FSB.

              Terminal out (CPU governor messages omitted)

              $ sudo lfsb -d 14 ics9lprs355 166

CPU frequency : 1197.03 MHz (estimated)
PLL ics9lprs355 is supported (untested)
DEBUG: Using device '/dev/i2c-14'
unhide DEBUG: 32 bytes read   : 37 85 FC 77 FF F0 30 11 D0 65 7D 00 20 CF 44 EF 2F A0 8F F2 23 01 CE 61 53 D8 75 05 C2 00 AD CA 
CheckTME DEBUG: 32 bytes read : 37 85 FC 77 FF F0 30 11 D0 65 7D 00 20 CF 44 EF 2F A0 8F F2 23 01 CE 61 53 D8 75 05 C2 00 AD CA

Trusted Mode Enabled, PLL is TME locked.
DEBUG: Using device '/dev/i2c-14'
GetFSB DEBUG: 32 bytes read : 37 85 FC 77 FF F0 30 11 D0 65 7D 00 20 CF 44 EF 2F A0 8F F2 23 01 CE 61 53 D8 75 05 C2 00 AD CA 
FSB=133 MHz

Changing to:
FSB=166 MHz
WARNING: Too high FSB/PCI/AGP speed can DAMAGE your hardware!
Continue [y/N]: y
DEBUG: Using device '/dev/i2c-14'
tmefix DEBUG: 32 bytes read    : 37 85 FC 77 FF F0 30 11 D0 65 7D 00 20 CF 44 EF 2F A0 8F F2 23 01 CE 61 53 D8 75 05 C2 00 AD CA 
tmefix DEBUG: 32 bytes written : 37 85 FC 77 FF F0 30 11 D0 65 7D 00 20 CF 44 EF 2F A4 F6 F2 23 01 CE 61 53 D8 75 05 C2 00 AD CA 
SetFSB DEBUG: 32 bytes read    : 37 85 FC 77 FF F0 30 11 D0 65 7D 00 20 CF 44 EF 2F A0 8F F2 23 01 CE 61 53 D8 75 05 C2 00 AD CA 
SetFSB DEBUG: 32 bytes written : 37 85 FC 77 FF F0 30 11 D0 65 7D 00 20 48 29 EF 2F A0 8F F2 23 01 CE 61 53 D8 75 05 C2 00 AD CA 
FSB frequency changed.

CPU frequency : 1197.01 MHz (estimated)
FSB=166 MHz


$ sudo lfsb -d 14 ics9lprs355
CPU frequency : 1197.02 MHz (estimated)
PLL ics9lprs355 is supported (untested)
DEBUG: Using device '/dev/i2c-14'
unhide DEBUG: 32 bytes read   : 37 85 FC 77 FF F0 30 11 D0 65 7D 00 20 CF 44 EF 2F A0 8F F2 23 01 CE 61 53 D8 75 05 C2 00 AD CA 
CheckTME DEBUG: 32 bytes read : 37 85 FC 77 FF F0 30 11 D0 65 7D 00 20 CF 44 EF 2F A0 8F F2 23 01 CE 61 53 D8 75 05 C2 00 AD CA

Trusted Mode Enabled, PLL is TME locked.
DEBUG: Using device '/dev/i2c-14'
GetFSB DEBUG: 32 bytes read : 37 85 FC 77 FF F0 30 11 D0 65 7D 00 20 CF 44 EF 2F A0 8F F2 23 01 CE 61 53 D8 75 05 C2 00 AD CA 
FSB=133 MHz
               

              Last edit: Sasyn 2013-02-27

  • Nick Kislitsa

    Nick Kislitsa - 2013-02-27

    That's strange. :)
    Does makefile has this line 'LIBS=-lm -lrt' ?

     

    • Sasyn

      Sasyn - 2013-02-27

      yes, but I believe it doesn't work because it is stated before the project files.

      http://stackoverflow.com/questions/2418157/ubuntu-linux-c-error-undefined-reference-to-clock-gettime-and-clock-settim

       

      • Nick Kislitsa

        Nick Kislitsa - 2013-02-27

        Ok. Moved to end of line.

         

  • Sasyn

    Sasyn - 2013-02-28

    Looking at the debug info it seems all bytes are written when tme-fix is run, but bytes 17 and 18 revert to old data before the FSB is set. This seems to cause bytes 13 and 14 to revert too.

    The order seems to match this article on the same procedure, so I'm not sure what is wrong. The i2c dump on that page before starting only seems to have trivial differences in bytes 3, 6 and 12.
    I tried setting bytes 17 and 18 at the same time as 13 and 14 but with no effect.

     

    Last edit: Sasyn 2013-02-28

    • Nick Kislitsa

      Nick Kislitsa - 2013-02-28

      It seems that TME workaround does not work.

       

Log in to post a comment.