[SOLVED] Tek MSO4104 no boot

[pcwrangler]

Hi all, I just got a Tektronix MSO4104 (Serial C0204xx) that won't boot. Upon power-up the screen flashes briefly and the fans go full speed about 5-7 seconds later. All voltages except 17v are present and I don't see anything burned. I can't find what the 17v is for or where it goes on either side of the main board. Nothing significant on an infrared camera. I tried a "forceinstall" of the firmware from USB (front and back ports) but the drive never flashes so it doesn't even get that far. I have read all the threads I can get my eyes on and can't find anything that helps. A couple mention a "console" serial port to watch the power up process but nobody appears to know the location of this port or the pinout. Of course I don't have a schematic (thanks Tek) and the manuals are pretty worthless in this scenario. Can anyone provide guidance?

Is this just a failed firmware upgrade? If so, is there a way to back up the calibration info before I pull the chip and program it?

Any help would be GREATLY appreciated!
 

[pcwrangler]

UPDATE: I am starting to believe this unit was assembled with failed parts for resale. I found 2 problems which I'm sure aren't related to the non-boot issue but are still interesting.

1. Since it wouldn't read the USB drive when I tried force-updating the firmware I checked voltages and noticed the USB ports start at 5v and slowly drop. If I measure the voltage it drops quicker and when I plug in a drive it drops to 1v instantly. I traced this 5v supply to power distribution switch TPS2023 at U310. Inputs are stable during failure. The only other things I see on this line are the capacitors C410 and C220, 470uF. I will have to make sure these aren't pulling the supply down before I replace U310.

2. The inverter isn't providing AC to the backlight. I can see 12V DC leading into transistor Q1, RSS075P03. I still need to investigate this circuit. I have confirmed the screen is blank with a bright flashlight.

The voltage measurements are below. I still haven't determined what the 17v is for. I understand the mso4000 and dpo4000 series are similar so maybe they used this board for other revisions and the 4104 doesn't use 17v?

Label--Measured
-12                  -11.978
-5                    -5.2335
1.5                   1.4943
1.8                   1.8415
2.5                   2.4972
3.3                   3.3123
5varly               4.0885
5va                   5.0768
5                       5.1065
10.8                  10.816
12                     12.083
17                     0
Probe Pwr 12v    0

Anyways, I'm still at it if anyone wants to contribute. I will keep updating this thread and hope it helps someone in the future.

[pcwrangler]

UPDATE

1. TPS2023 at U310 is bad. I confirmed by injecting 5v from my bench supply and it only took about 70mA, powering my USB tester. I'll replace this when I solve the boot issue.

2. The inverter is fine and wasn't receiving the enable signal. Luckily the 104PW191 by NEC has a datasheet and I was able to confirm the voltage to inject and it lit up the backlight perfectly.

Next step is to check the ram activity and some of the address lines to confirm CPU activity. More to come.

[pcwrangler]

Thanks to ApertureScience for the serial pinout I was able to observe my boot log process.

The Tx Pin is located on the 20-pin connector at the bottom. With the screen facing up, its the 2nd pin in the first row.
Good read on the topic: https://debugmo.de/2013/03/whats-inside-tektronix-dpo5034/

My Bootlog:

CPU:   AMCC PowerPC 440EP Rev. C at 333.333 MHz (PLB=133, OPB=66, EBC=66 MHz)
       I2C boot EEPROM enabled                                               
       Internal PCI arbiter enabled, PCI async ext clock used               
       32 kB I-Cache 32 kB D-Cache                                           
Board: Tektronix Route66 IBM 440EP Main Board                               
        VCO: 666 MHz                                                         
        CPU: 333 MHz                                                         
        PLB: 133 MHz                                                         
        OPB: 66 MHz
        EPB: 66 MHz
I2C:   ready
DRAM:  128 MB
F

As seen in the thread linked above, the F should be the "Flash:" line and continue the boot process but it just halts. I confirmed all activity on the address lines also halt at this point. I have repeated this process a dozen times with the exact same results. Does this mean I have a bad CPU or maybe flash? If it is just bad instructions in flash, I can de-solder and program it manually if necessary. I assume the calibration would be lost but a working scope is an improvement.

Any guidance would be great. Thanks for the eyeballs. 

[pcwrangler]

I have returned to this project and need to consolidate parts of this from another thread (https://www.eevblog.com/forum/repair/tektronix-dpo4054-stucked-at-tektronix-splash-screen/msg3459646/#msg3459646) for my own documentation/sanity. The key points are below.

The oscillator at Y650 is 27MHz and looks good, steady through the whole process.
There are two LTC3728 and one LTC3729 that all look ok. The PGOOD signal on all of them isn't pulled down.
The EEPROM at U431 has steady power but no activity on the one address line that isn't directly tied to ground. There are only 2 pulses low on the SDA and one on the SCL upon boot, exact same results every time.

All oscillators on both sides are present and stable. The CPU does have an integrated PLL.
I checked every pin imaginable from the vias under the CPU BGA. The only suspect was clkEn which enables the RAM clock. It is steady at 2.2v instead of the documented 2.5v in the CPU datasheet. However,  I believe that is still within SSTL 2 specs.
I confirmed the CPU bootstrap is configured to gather boot configuration from the 16 bytes on the I2C EEPROM. I believe that is telling the CPU to get the bootloader from the 4MB flash chip at U822. The CE and OE pins between the CPU and U822 start enabled and then go high at the same time the boot log stops. I think bootloader instructions are interrupted because of this. I just don't know why the CPU is doing this.
I confirmed the DDR termination regulator is at U650 and is behaving as specified in the datasheet.
Sadly, I have ruled out voltages, DDR termination and oscillators.
U822 is a Am29LV040B PLCC. Does anyone have a dump of this chip? This MSO4104(non-B) has the same version header as others have posted from different versions of the 4000. "U-Boot 1.1.4 (Jan  8 2007 - 11:12:14) Tektronix, Inc. V1.06". I'm not sure if that means it's universal and interchangeable but I also found this same version digging through the downloadable FW update from Tek. Maybe I'll desolder and compare the two.
IR Cam shows no overheating either side of board.

After desoldering and dumping the existing code on U822 I can see it contains more than just the bootloader. I compared it to the bootloader.img obtained via 'binwalk -e' of the latest firmware from the Tektronix website. Some fancy dd work on this might merge them, overwriting the bootloader portion to make things work but I would rather receive a U822 dump from someone else in the community so I know it is a functional copy. The results are below.

binwalk of U822 dump (524KB)

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
295           0x127           Unix path: /vol/ibunix01/r66tools/r66tools/mvserve/filesys
1370          0x55A           U-Boot version string, "U-Boot 1.0.0 (Sep  8 2006 - 08:50:07) Tektronix, Inc. V1.02"
262144        0x40000         uImage header, header size: 64 bytes, header CRC: 0x552D426F, created: 2029-04-03 03:29:53, image size: 774975028 bytes, Data Address: 0x20284A61, Entry Point: 0x6E202038, data CRC: 0x20323030, image name: "11:12:14) Tektronix, Inc. V1.06"
262148        0x40004         U-Boot version string, "U-Boot 1.1.4 (Jan  8 2007 - 11:12:14) Tektronix, Inc. V1.06"
381312        0x5D180         CRC32 polynomial table, big endian
386984        0x5E7A8         U-Boot version string, "U-Boot 1.1.4"
414044        0x6515C         Unix path: /vol/ibunix03/r66tools/r66tools/mvserve/filesys

binwalk of bootloader.img from Tek (262KB)

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x552D426F, created: 2029-04-03 03:29:53, image size: 774975028 bytes, Data Address: 0x20284A61, Entry Point: 0x6E202038, data CRC: 0x20323030, image name: "11:12:14) Tektronix, Inc. V1.06"
4             0x4             U-Boot version string, "U-Boot 1.1.4 (Jan  8 2007 - 11:12:14) Tektronix, Inc. V1.06"
119168        0x1D180         CRC32 polynomial table, big endian
124840        0x1E7A8         U-Boot version string, "U-Boot 1.1.4"
151900        0x2515C         Unix path: /vol/ibunix03/r66tools/r66tools/mvserve/filesys

assuming the flash chip is ok, I think the cpu stalls when she wants to communicate with a peripheral device/chip and perhaps does not get the right response/acknowledge. At this early stage I think it is more likely to be a device on the PCI bus

Code: [Select]

PCI:   Bus Dev VenId DevId Class Int
        00  13  10b5  9056  0680  18
        00  15  1002  4c59  0300  17

the first device is the PCI Bus Master chip made by PLX (PCI9056) and the second device in the list is the ATI Mobility Radeon graphics processor
but how to troubleshoot their connection? is beyond me...

vcc and clock are good on the PCI9056 at U560 but the IDSEL(thanks m k) line is stuck low. The datasheet of this chip and the 440EP CPU show their IDSEL pins as input. Anyone know the source?

BTW: I programmed the flash with the downloaded and extracted bootloader.img just to see what would happen but it wouldn't even provide a boot log, completely dead. I reprogrammed it with the original code and it's back to the previous behavior. I thought I would add this here just in case someone is playing with firmware in the future. I suppose a merge of that img file with the original code might work but I believe you all are correct; if it was damaged I wouldn't get much useful info out of it.

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.

[pcwrangler]

UPDATE: SOLVED! User adrianh resolved a different issue on his 4104 in this thread: https://www.eevblog.com/forum/repair/tektronix-dpo-4104-kernel-panic/
So I asked him about my issue and with his guidance I replaced the DRAM. Problem solved! I can't believe it was that simple the whole time. I'm very grateful to adrianh as this saved a very expensive (to me) piece of gear. 

Anyways, in that thread he speculated that this line of scopes might have failing/faulty RAM and that definitely fits my case so I encourage anyone that is having early U-Boot problems to keep this in mind.

[pcwrangler]

For the record: The bad ram was the bottom one on the back side (opposite of CPU) of the board.

[daveyk]

Wow; congrats.  Yes these are expensive scopes.  What kind of ram was it?  SMD with legs, or ball grid?

I got mine at Goodwill auction but still had to pay about $3400.

Dave

[pcwrangler]

It was a 66 pin TSOP I believe. Exact model is MT46V16M16. Now I just have to worry about the inevitable CCFL failure/dimming. Still, it's a great scope.. especially after you add licenses. Check other threads about the MSO/DPO series if you are so inclined. 

[myhobo]

Hi pcwrangler,  I need the boot code in AM29LV040B, my MSO4034 can't start u-boot, please send me the file, thank you very much.

[pcwrangler]

I'd be happy to send that to you but I would be very surprised if that was your problem unless you have a specific failure of that chip or some other indication that the code has gone bad. Have you dumped the existing code from that chip yet? What's the boot log look like?

I'll send you the dump I have but remember it is the MSO4104(NON-B). I doubt that matters having examined how the firmware updates work but I could be wrong. Check your messages in the next few minutes.

Good luck

[pcwrangler]

It appears I cannot attach files in a PM. Well, hope this doesn't get taken down. Here you go.

[myhobo]

thank you pcwrangler, It's working

[myhobo]

excuse me, I need you help , this is my serial port output information :
CPU:   AMCC PowerPC 440EP Rev. C at 333.333 MHz (PLB=133, OPB=66, EBC=66 MHz)
       I2C boot EEPROM enabled
       Internal PCI arbiter enabled, PCI async ext clock used
       32 kB I-Cache 32 kB D-Cache
Board: Tektronix Route66 IBM 440EP Main Board
   VCO: 666 MHz
   CPU: 333 MHz
   PLB: 133 MHz
   OPB: 66 MHz
   EPB: 66 MHz
I2C:   ready
DRAM:  128 MB
FLASH: 64.5 MB
PCI:   Bus Dev VenId DevId Class Int
        00  13  10b5  9056  0680  18
        00  15  1002  4c59  0300  17
DISP:  Type 1
In:    serial
Out:   serial
Err:   serial
Enter password - autobooting in 3 seconds
## Booting image at f0000000 …
Bad Magic Number
## Booting image at f0180000 …
Bad Magic Number
=>



What should I do next?