[weblacky]

This data sheet will show you: https://www.st.com/resource/en/datasheet...br12sh.pdf

[HarryT]

This data sheet will show you: https://www.st.com/resource/en/datasheet...br12sh.pdf

Thank you very much, it is the temperature range. I have ordered one.

[weblacky]

Hi, I assume you meant the voltage range.

The data sheet showed the various voltages and such that it should be as well as the pins that the battery is connected to.

To be clear, I’ve still not seen this particular error before. But all we can do is look at the fundamentals at this stage. So first we need both of your RTC‘s to work. Then when the system resets you may need to perform an overall reset of the logs and features. Then we may see a different problem.

Be very aware that the first time you boot the serial number needs to transfer between one system to another automatically. So your first boot after installation of the Snaphat may not be successful. But assuming everything is working your second attempt at booting should provide you with more answers.

Best of luck and do keep us informed. As this is a new symptom I’ve not seen before.

[HarryT]

Hi, I assume you meant the voltage range.

The data sheet showed the various voltages and such that it should be as well as the pins that the battery is connected to.

To be clear, I’ve still not seen this particular error before. But all we can do is look at the fundamentals at this stage. So first we need both of your RTC‘s to work. Then when the system resets you may need to perform an overall reset of the logs and features. Then we may see a different problem.

Be very aware that the first time you boot the serial number needs to transfer between one system to another automatically. So your first boot after installation of the Snaphat may not be successful. But assuming everything is working your second attempt at booting should provide you with more answers.

Best of luck and do keep us informed. As this is a new symptom I’ve not seen before.

Thank you again. The module is announced for delivery on June 8th.

[HarryT]

Best of luck and do keep us informed. As this is a new symptom I’ve not seen before.

I installed now a new STMicroelectronics M4T32-BR12SH1 and also a new DS1742W, but still the same error/ problem. System does not boot.
Any ideas?

[weblacky]

Please do not replace your DS1742w!!!

You cannot replace both at once you have to successfully replace one before you replace the other or system will not boot. We’ve already tested this. Both cannot be in flux or misconfigured or you’ll not boot.

Please put back your old DS1742w with the new Snaphat and troubleshoot that system.

Also, I’ll need to check the console output (if any) at the L1 console port using ctrl+d and Ctrl+t toggling on the console keyboard.


The point of this was that you likely had a dead Snaphat. You need to boot with a working one and then you need to switch to your “console output” during post (or whatever part you have of post) on the l1 cmd port.

See if you can do a control+d before auto power up attempt and see if new output occurs that you’ve not seen before to give us new info on what is going on.

We need to know how far into POST your firmware is getting.

The L1 is on all the time and is merely a management system for hardware and it’s own image. It then boot straps the main CPU Firmware image to begin booting the system.


Please attach a serial terminal (like before) switch on the Tezro after you’ve connected the terminal and are live. When you see the L1 command prompt quickly try to do a control+d (may need to try repeatedly, over a few seconds) to switch to the console output from L1 output. Hopeful you’ll see more output as firmware boots and then the CPU exception occurs. It should show memory size, loading scsi and graphics, etc.

I’m assuming you’ll get to the memory checking and then start booting and then a new message will happen that hopefully show us more about what’s going on.


As we’ve stated we cannot be of help with the message you already know as it has no real info and no one has seen it before, so we need to see if that hidden console output can be seen and what (if anything) it says.

Please read printed page #23: https://irix7.com/techpubs/007-3938-003.pdf

Thanks

---

Also since there has been chip swapping we need you to check your embedded serial number. If this is gone, your Tezro will not boot properly and you’ll get weird CPU errors sometimes. The RTC that uses the yellow snap hat holds a copy of the serial as well as the other RTC as well as one another chip that is read only. This is why swapping chips can be very problematic because you can only program one chip at a time with the auto set up system. If this fails, you won’t have a valid serial number in all the multiple places it’s supposed to.

From the L1 command prompt type: serial all


And post the output to the forums. The system should not need to be in auto power up to use this command. You should be able to use it from first level L one while the system is not running.

Thanks.

[HarryT]

Please do not replace your DS1742w!!! 

You cannot replace both at once you have to successfully replace one before you replace the other or system will not boot. We’ve already tested this.  Both cannot be in flux or misconfigured or you’ll not boot.

Please put back your old DS1742w with the new Snaphat and troubleshoot that system. 

Also, I’ll need to check the console output (if any) at the L1 console port using ctrl+d and Ctrl+t toggling on the console keyboard. 


The point of this was that you likely had a dead Snaphat.  You need to boot with a working one and then you need to switch to your “console output” during post (or whatever part you have of post) on the l1 cmd port. 

See if you can do a control+d before auto power up attempt and see if new output occurs that you’ve not seen before to give us new info on what is going on. 

We need to know how far into POST your firmware is getting. 

The L1 is on all the time and is merely a management system for hardware and it’s own image. It then boot straps the main CPU Firmware image to begin booting the system. 


Please attach a serial terminal (like before) switch on the Tezro after you’ve connected the terminal and are live.  When you see the L1 command prompt quickly try to do a control+d (may need to try repeatedly, over a few seconds) to switch to the console output from L1 output.  Hopeful you’ll see more output as firmware boots and then the CPU exception occurs.  It should show memory size, loading scsi and graphics, etc. 

I’m assuming you’ll get to the memory checking and then start booting and then a new message will happen that hopefully show us more about what’s going on. 


As we’ve stated we cannot be of help with the message you already know as it has no real info and no one has seen it before, so we need to see if that hidden console output can be seen and what (if anything) it says.

Please read printed page #23: https://irix7.com/techpubs/007-3938-003.pdf

Thanks

---

Also since there has been chip swapping we need you to check your embedded serial number. If this is gone, your Tezro will not boot properly and you’ll get weird CPU errors sometimes.  The RTC that uses the yellow snap hat holds a copy of the serial as well as the other RTC as well as one another chip that is read only. This is why swapping chips can be very problematic because you can only program one chip at a time with the auto set up system. If this fails, you won’t have a valid serial number in all the multiple places it’s supposed to.

From the L1 command prompt type: serial all


And post the output to the forums.  The system should not need to be in auto power up to use this command. You should be able to use it from first level L one while the system is not running.

Thanks.

Many thank's for your fast answer.

The embedded serial number seems to be correct (Local System Serial Number and Reference System Serial Number same like on the back of the tezro). When I switch in the serial terminal after "pwr u" to control+d, I will get:

Code:

no response from 001c01 CPU0, system not responding

control+d before powering up gives us:

Code:

WARNING: power on 001c01 appears off!

[weblacky]

So you get this output right up until the exception? No verifying the time you wait produces a different output?


Hmmm…. Can you show us the details version of your L1?

Also what CPU (IP NODE) board do you have?

What version of Irix was last attempted or installed on this machine?

---

—————-
Can you show us the output from the l1 cmd: leds

[HarryT]

The IRIX version installed on the tezro is 6.5.28f.
reboot_l1 gives us

Code:

SGI SN1 L1 Controller
Firmware Image A: Rev. 1.30.11, Build 07/16/2004 07:53:59

The system is the IP53 quad 700Mhz version (discreet flame setup).

Code:

001c01-L1>cpu
CPU Present Enabled
--- ------- -------
0A    1       1
0B    1       1
0C    1       1
0D    1       1  

[weblacky]

OK so it’s not due to a disabled CPU.


Your firmware version of your L1 concerns me though that version of Irix does not use that firmware normally. It doesn’t mean it can’t work but that’s kind of unusual. Can you show me both your L1 flash blocks?

I’m thinking that maybe you booted into your auxiliary back up slot that carries a firmware revision that’s older and causing this problem. Can you see if you have a newer firmware in your L1 slot B and reboot into it?