Electronics > Repair
Tektronix DPO4054 stucked at tektronix splash screen
<< < (13/16) > >>
analogRF:
could it be that CPU is receiving a false interrupt from a device onboard?
m k:
Good, or bad, now it's at least known that something excact is clearly something it shouldn't.
Is it a cause is another thing.

I don't know the correct PCI naming policies and the whole PCI hierarchy has always been a bit messy.
A controller can also be PCI to PCI and then another PCI controller is what you think is the first one.
Did I read it right that this 440EP can also be a PCI controller, so the 2nd in PCI line.

One construction model is CPU-PLB-bridge-PCI-controller/bridge-stuff.
There is also a method called PCI boot, where PCI memory can be accessed without configuration, it can obviously be misused for what ever purposes.

In this case it's quite possible that PCI something is predefined.
Since the system knows that some parts are there, or should be, always, it can expect them.

So if PCI 9056 is not first its missing ID request can be fine, but since that other boot log has it as first, one must follow that.
Though it doesn't exclude that there isn't something else before that but would it be completely silent in the log.

For the interrupt,
if it's PCI and not configured it should be ingnored.

One method for IDSEL is to decode one address line for each PCI connection IDSEL.
PPC440EPx-GRx manual says that device 1 is AD11.
If those addresses are used elsewhere there must be a chip with enable in between somewhere.

ApertureScience:
So i'm back on my project!
I got some compatible RAM chips and found a shop that can swap them for me.
To understand the error messages better I reversed the firmware, but nothing especially helpful came up. To tackle the 10_calDramStep29 error i wanted to narrow down the selection of the 4 ram chips associated with DEMUX 3 (aka U370).

Now the part that is pure speculation. The error message format goes:
Diag Failure: Mode 100 4, U370,U480,U0471,U470,U0462, 0x00000000 0x00000001 0x00000001
What had me confused is that four RAM chips are listed with three memory adresses. I thought those were supposed to be the memory addresses currently on the DEMUX buses, even though there should be four then. But I think these are linked to the DRAM groups D and DC quoted by an error message before:
dmx 03 ERROR: 10_calDramStep29: Dram1 GrpD 29.2.4 byte 97: exp/act 0x06/0x0e (bits: 3) 
dmx 03 ERROR: 10_calDramStep29: Dram1 GrpDC 29.2.4 byte 99: exp/act 0x06/0x36 (bits: 4 5)
Hence why the second and third address are always the same. My guess would be that that group D and C are the third and fouth RAM probably, so U470 and U0462.

Does somebody have an opinion on that?
ApertureScience:
I will also try to reball the DEMUX.
ApertureScience:
Regarding the acqUpWriteLong failed error, in the firmware i found the function outputting it. I have no idea what it does! Raw decompiled code ahead :scared:

--- Code: ---undefined8 acqUpWriteLong(ulong *param_1,ulong param_2,uint param_3,int param_4)

{
  undefined4 uVar1;
  uint uVar2;
  undefined4 in_LR;
 
  uVar2 = CDmxUpXfr::write(*(CDmxUpXfr **)
                            (*(int *)(*(int *)(CDemuxs::m_physicalToLogicalIndexMap + param_4 * 4) *
                                      4 + CDemuxs::m_dmxs) + 0x40),param_1,param_3,param_2);
  uVar1 = 0;
  if (uVar2 != param_3) {
    errPrintf("acqUpWriteLong failed\n");
    uVar1 = 0xffffffff;
  }
  return CONCAT44(uVar1,in_LR);
}

--- End code ---
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod