[weblacky]

Hi Weblacky,

the obvious one is the big on front side, near the serial part no label

The problem is that a bunch of the smaller surface mount tantalum capacitors have been knocked off the bottom of the board... (not really easily seen on photo, but on inspection you can see where some have been knocked off the board).

I will mark up what I can see and start new thread for that...

Also I did a bit of a web surf for 28 PIN Test Clip and found this: https://www.farnell.com/datasheets/193574.pdf

But at 32K Bytes that chip does not provide enough space for the ~ 1.5 M Bytes that was written / dumped...

So still not clear if this is the right chip.

Cheers from Oz,

jwhat/John.

 Hmm...It's not obvious to me as I cannot see anything near a serial port (side or L1) that doesn't have markings and is missing.  I do see a fair amount of scratch/strike damage on the back and can see where more than few small SMD components might be.


Please just take some time to carefully markup the pictures to show missing areas to make it easier for me to tell what's what.  Right now I cannot even locate the top one you're talking about.

[jwhat]

Hi Weblacky,

I started doing a really close inspection of the bottom of the board...

It is bad!

Much worse than I initially thought.

It is not just capacitors, there are 8 pin chips missing and some of the larger ICs have got damaged pins...

So you would have to take off some of the larger ICs and replace them.

The problem is that even if you did lots of work, you would probably find it still did not work and it would be impossible to diagnose the cause.

A real shame as it is late model board, but I am putting this back into storage box.

Cheers from Oz,

jwhat/John

[weblacky]

That’s sure is a shame, I agree.

[weblacky]

So....I'd like to give this a kick in the pants. Once I try to repair the 600Mhz PIMM, I'll want to insert it into my Fuel...so that would be the chance to try fetching memory regions or perhaps writing to a region.

So did you guys come to any conclusions on the memory offsets to the struct you found and what to fill in? This is above my experience so I can only like query things and set things.

I have a 700Mhz PIMM installed and running now, I'd be putting in a 600Mhz for test. It would be nice to find out some more info to actually have actionable things to do next week.

So I wanted to dump my current config values and also try to fiddle with the values once the alternate PIMM is installed. I assume I can just set debug to 10 and stop at local POD and fiddle. What to fiddle with...

It seemed things were extremely close just a few posts ago, you had the memory offset for the start of the struct and basic offsets for elements. I guess we still need the checksum method (I assume it's a two's complement, rolling checksum).

Is there a way we can sort of finish this? Or at the very least get the commands to dump this region for later examination/comparisons?

[jwhat]

Hi Weblacky,

on progress front, I did some digging into POD/CAC and tried testing a couple of commands, in particular:
>> A 000 001c01: Rd sysctlr nvram: scr ADDR [COUNT]

To see if I could read the PROM and validate data against the dump data.

Initially it seemed to take the ADDR and just echo'ed it as HEX so I tried to use HEX address and set what that provided:
>> scr 0x160 8 (where 0x160 was starting address of PROM where the CPU speed was stored)

This did not seem to be to provide any valid output in my initial testing so need to try again.

If you found the right PROM location then you could try:

>> A 000 001c01: Wr sysctlr nvram: scw ADDR [VAL [COUNT]]

This could be very very dangerous though as if you clobber the wrong thing it could brick the entire Fuel...

Before doing this I would like to know we had some recovery mechanism , like ability to re-program PROM chip ...

I know that you have speculated on being able to change in RAM data, but how would we know where this data is loaded (read the source code) ?
Also if the PROM was pulled into memory with slower than "PROM-ified" ;-) CPU then this would also put weight to CPU speed change on boot..

As part of your testing it might be helpful , just to see what happens if you put slower CPU into machine and see if you an get to POD/CAC mode.

If so then this would mean that machine is starting with some default CPU speed and then changes speed as part of boot process...

I think we need to make sure we have some emergency parachutes available or we get some more definitive direction.

Currently the only person who has made reference to this is Toby Jenkins/Jennings from what was 3-D Systems in UK via Nekochan...

And if he knew then it is likely he go info from a SGI field engineer, as this would allow them to upgrade customer systems without need to have root access.

Cheers from Oz,

John Hartley.

[weblacky]

Yo,
We may know where the prom is loaded. It says it every time at console boot up (prom copied to ram) with a location (this was stated before as well). This is why I wanted help because there’s still a little bit of math involved until we know where the heck we are.

Return to post #75: http://forums.irixnet.org/thread-2164-po...l#pid22879

Those values with a get should do something. I’m very certain it makes more sense that we are working with the memory shadow copy. Just like the way most PC BIOS work by shadow copy, where often they copy to memory and then the values can be fiddled with and ROMs can be inserted. I know it doesn’t have to work this way. But it often does.

I say this because if you check your console boot up you’ll see the graphics prom loading a graphics module like a ROM. To me this implies that the reason that prom code is copied to memory is because that is the way it is used. I don’t believe for a moment that the running prom MIPS code directly accesses the flash region after initial copy/load of prom image. I think this is why you have to go through this awful flashing a CPU speed anyway because of chicken or the egg. I also think because of such a low programming counter that the programmers did not want to access this flash region very much to prevent degradation. So they obviously don’t write back to it other than to flash it. So any modifications must be done at runtime and in memory. Otherwise there wouldn’t be such an incredibly low and delicate flash counter on this system, if they could just write bits of stuff to it here and there.

So I’d say just see if you can try doing the bytes @ at source you were doing before but use the new found address.

In other words base all your offsets on the base of 0x9000000100000000.

[jwhat]

Hi Weblacky,

yes agree that the boot strap process will load the PROM into memory and execute from there.

But the CPU Speed configuration is persistent, so "flash" program is updating the EEPROM.

While we can poke stuff into memory, any such change will not be persistent across boots.

I have a copy of the "See MIPS Run" book and it has details on the "MIPS CPU Control Registers" and there is nothing there that relates to CPU Speed Control.

CPU Speed is managed via external clock in systems of this era, I would have thought (unlike current Intel and other CPUs which have variable speed based on load/battery level etc).

This is is why I am wondering how speed is managed.

If the speed is encoded as data in the PROM then it implies there is some software control mechanism ocurring...

First something is loading the data, as part of PROM code (that would have to be the main CPU) and then based on that it is sending some control request to clock to ensure it runs at the correct speed.

Hence my speculation on starting at one speed and then changing speed based on data value.

Is the CPU clock a seperate chip on the PIMM board ?

I guess the alternative is that the data in PROM is just used for internal calculations and reporting use and does not have any role in actual control of clock. In this case the "flash" process also "sticks" some data somewhere else which is used to control Clock speed.

Given that there are POD/CAC instructions to read/write to PROM and that is where the speed data is I will think you can use these.

We just need to get syntax right, starting with reading first ;-)

But it is easy for me to see what is reported from RAM ...

I will do some further testing on weekend.

As electronics person, could you look at PIMM for the CPU clock chip ?

Cheers from Oz,


jwhat/John.

[weblacky]

Hi Jwhat,
We don't need (nor want) persistence. We only need it to boot to like a installation INST Admin miniroot from like CDROM, then do normal flashing. I never considered this a "safe" way of changing speeds...only a workaround. I know the nekochan thread hints otherwise.

POD mode is the only solution for being painted into a corner, but you still need to update flash across two boards...I never assumed we do that in POD...we do that in flash...but with a one-time-boot trick...we can get to boot...so we can flash.

I only expected that much.

---

I don't know about CPUs but most SGI seems to have external oscillators and some kind of setup. Otherwise, I don't know...nor do I think it's worth looking into given what we need vs. want.

[jwhat]

Hi Weblacky and vvuk,

some more POD/CAC explorations...

>> A 000 001c01: POD SysCt Cac> segs
>> A 000 001c01: Segment 0: io7prom
>> A 000 001c01: Flags: 0x13
>> A 000 001c01: Offset: 0x1000
>> A 000 001c01: Entry addr: 0xc000000013000140
>> A 000 001c01: Load addr: 0xc000000013000000
>> A 000 001c01: True len: 0x166a16
>> A 000 001c01: True sum: 0x5fba51e
>> A 000 001c01: Cmprsd len: 0xa0231
>> A 000 001c01: Cmprsd sum: 0x5499f92
>> A 000 001c01: Memory len: 0xa8a4f0

>> A 000 001c01: POD SysCt Cac> la 0x9000000100000068 8
>> A 000 001c01: 9000000100000068: \000 \000 \000 \000 \000 \000 \000 \000

>> A 000 001c01: POD SysCt Cac> pcfg v
>> A 000 001c01: SN0net Topology (node 0):
>> A 000 001c01: ENTRY 0: HUB(52275dad)
>> A 000 001c01: NASID=0 Mod=1 Flg=0x9500000 PROM=6.211 Route=N/A
>> A 000 001c01: MODULE=001c01 PARTITION=0 SPACE=RESET

>> A 000 001c01: POD SysCt Cac> cfg
>> A 000 001c01: *** Config values flashed in the PROM ***
>> A 000 001c01: CPU speed = 800 MHz
>> A 000 001c01: HUB speed = 200 MHz
>> A 000 001c01: Register: Config (16) 0x00000000549baf85
>> A 000 001c01: <2:0> Kseg0CA = 5
>> A 000 001c01: <4:3> DevNum = 0
>> A 000 001c01: <5> CohPrcReqTar = 0
>> A 000 001c01: <6> PrcElmReq = 0
>> A 000 001c01: <8:7> PrcReqMax = 3
>> A 000 001c01: <12:9> SysClkDiv = 7 (4)
>> A 000 001c01: <13> SCBlkSize = 1 (32)
>> A 000 001c01: <14> SCCorEn = 0
>> A 000 001c01: <15> MemEnd = 1
>> A 000 001c01: <18:16> SCSize = 3 (4 MB)
>> A 000 001c01: <21:19> SCClkDiv = 3 (2)
>> A 000 001c01: <23> DDR = 1
>> A 000 001c01: <22|28:25> SCClkTap = 0xa
>> A 000 001c01: <30> ODrainSys = 1
>> A 000 001c01: <31> CTM = 0
>> A 000 001c01:
>> A 000 001c01: *** Config values loaded from nasid 0 CPU A ***
>> A 000 001c01: Register: Config (16) 0x000000006c9baf85
>> A 000 001c01: <2:0> Kseg0CA = 5
>> A 000 001c01: <4:3> DevNum = 0
>> A 000 001c01: <5> CohPrcReqTar = 0
>> A 000 001c01: <6> PrcElmReq = 0
>> A 000 001c01: <8:7> PrcReqMax = 3
>> A 000 001c01: <12:9> SysClkDiv = 7 (4)
>> A 000 001c01: <13> SCBlkSize = 1 (32)
>> A 000 001c01: <14> SCCorEn = 0
>> A 000 001c01: <15> MemEnd = 1
>> A 000 001c01: <18:16> SCSize = 3 (4 MB)
>> A 000 001c01: <21:19> SCClkDiv = 3 (2)
>> A 000 001c01: <23> DDR = 1
>> A 000 001c01:
>> A 000 001c01: *** Config values loaded from board/PIMM PSC ***
>> A 000 001c01: CPU speed = 800 MHz
>> A 000 001c01: HUB speed = 200 MHz
>> A 000 001c01: Register: Config (16) 0x00000000549baf85
>> A 000 001c01: <2:0> Kseg0CA = 5
>> A 000 001c01: <4:3> DevNum = 0
>> A 000 001c01: <5> CohPrcReqTar = 0
>> A 000 001c01: <6> PrcElmReq = 0
>> A 000 001c01: <8:7> PrcReqMax = 3
>> A 000 001c01: <12:9> SysClkDiv = 7 (4)
>> A 000 001c01: <13> SCBlkSize = 1 (32)
>> A 000 001c01: <14> SCCorEn = 0
>> A 000 001c01: <15> MemEnd = 1
>> A 000 001c01: <18:16> SCSize = 3 (4 MB)
>> A 000 001c01: <21:19> SCClkDiv = 3 (2)
>> A 000 001c01: <23> DDR = 1
>> A 000 001c01: <22|28:25> SCClkTap = 0xa
>> A 000 001c01: <30> ODrainSys = 1
>> A 000 001c01: <31> CTM = 0

>> A 000 001c01: POD SysCt Cac> rnic
>> A 000 001c01: Not implemented on IP34 platform

Note: when I tried to read PROM at address 0x160 it returned an error message...

Potentially of interest is: <12:9> SysClkDiv = 7 (4)

Could either of you have a look at this for your CPUs ?


Cheers from Oz,


jwhat/John.

[weblacky]

Did you try 0x9000000100000160 like I suggested?