Changes Boot behavior on XP1000 since 2013 (2017 Views)
Reply
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 26 of 46 (1,072 Views)

Re: Changes Boot behavior on XP1000 since 2013

Michael,

 

the 'fix', HP OpenVMS engineering is thinking about (see above), could be easily implemented with PATCH (just changing a '1900.' to a '1920.' value). If you're interested in that fix, I could probably guide you through SDA to obtain the offset, where this 'value' is stored in your SYS$CPU_ROUTINES_2208.EXE and provide you with the appropriate commands for PATCH ...

 

You'll need to first find the following instruction stream:

 

SDA> exa/ins exe$read_bbw+1b0+1d8-10;30
EXE$READ_BBW_C+00378:   BIS             R31,#X02,R25
EXE$READ_BBW_C+0037C:   BSR             R26,#X0000D0
EXE$READ_BBW_C+00380:   LDQ             R1,#X0020(FP)
EXE$READ_BBW_C+00384:   LDL             R0,(R4)
EXE$READ_BBW_C+00388:   LDQ             R18,#X0028(FP)
EXE$READ_BBW_C+0038C:   LDQ             R25,#X0040(FP)
EXE$READ_BBW_C+00390:   SLL             R1,#X30,R17
EXE$READ_BBW_C+00394:   LDA             R19,#X076C(R31)     <<< this loads 1900. into R19 
EXE$READ_BBW_C+00398:   SRA             R17,#X30,R17
EXE$READ_BBW_C+0039C:   LDA             R20,#X07D0(R31)    <<< this loads 2000. into R20
EXE$READ_BBW_C+003A0:   ZAPNOT          R1,#XFC,R21
EXE$READ_BBW_C+003A4:   CMPLT           R17,R0,R0
EXE$READ_BBW_C+003A8:   ZAPNOT          R18,#XCF,R18
SDA> eva 76c
Hex = 00000000.0000076C   Decimal = 1900
SDA> eva 7d0
Hex = 00000000.000007D0   Decimal = 2000

 

Then all you need to do is find that binary code in the image and patch a single WORD location to load 1920. (0x0780) instead of 1900. (0x76C) into R19...

 

SDA> exa EXE$READ_BBW_C+00394
EXE$READ_BBW_C+00394:  227F076C   "l..""

 

 

Volker.

Please use plain text.
Esteemed Contributor
H.Becker
Posts: 360
Registered: ‎04-09-2009
Message 27 of 46 (1,062 Views)

Re: Changes Boot behavior on XP1000 since 2013

[ Edited ]

You can dump the CPU image and search for "076c " and "07d0 " to find the file offset of the code with these literals. Yes, the binary code may be different, loading the literals into other registers. Also, the code sequence may be totally different from what was shown here. Therefore you may want to use an Alpha disassembler, for example the one which Digital made available, some time ago: srm_check. As far as I know, it is available from a Freeware CD. Google is your friend. Use this tool with -verbose to see the sections, their VAs and VBNs. Use -dump (and -output filename) to disassemble with VAs. Search it's output for the literals. However, the tool doesn't show you the file offset of the disassembled code. So you have to do some math to get from the image section offset to the file offset and VBN (you can double check with the output of analyze/image).

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 28 of 46 (1,047 Views)

Re: Changes Boot behavior on XP1000 since 2013

[ Edited ]

Michael,

 

the SYS$CPU_ROUTINES_xxxx.EXE images aren't that big, so you can easily dump them:

 

$ dump/out=x.x  dsa0:[VMS$COMMON.SYS$LDR]SYS$CPU_ROUTINES_1102.EXE

$ sea x.x " 227F076C "/win=(20,1)

Dump of file DSA0:[VMS$COMMON.SYS$LDR]SYS$CPU_ROUTINES_1102.EXE;1 on 13-FEB-2013
 11:26:13.06
File ID (319,3,0)   End of file block 146 / Allocated 147

Virtual block number 80 (00000050), 512 (0200) bytes

 47E09410 223D0026 23620040 47FF041F D34000E8 A4820028 47E05419 47E05410 .TàG.Tà
G(..¤è.@Ó...G@.b#&.="..àG 000000
 D34000DC 47E05419 47E0F410 223D0024 23620040 47FF041F D34000E2 47E05419 .TàGâ.@
Ó...G@.b#$.=".ôàG.TàGÜ.@Ó 000020
 23620040 47FF041F D34000D6 47E05419 47E11410 223D0022 23620040 47FF041F ...G@.b
#".="..áG.TàGÖ.@Ó...G@.b# 000040
 A73D0040 A65D0028 A0040000 A43D0020 D34000D0 47E05419 223D0020 47E13410 .4áG .=
".TàGÐ.@Ó .=¤....(.]¦@.=§ 000060
 44130494 4A59F632 422009A0 483F9635 229F07D0 4A261791 227F076C 48261731 1.&Hl..
"..&JÐ.."5.?H.. B2öYJ...D 000080
 23620058 46B60401 47E17411 4A207636 A7420020 42340411 47E9D410 B65D0028 (.]¶.Ôé
G..4B .B§6v J.táG..¶FX.b# 0000A0

 

$ offset=(%x50-1)*512+%x80+4   ! VBN-1 * 512 bytes/block + offset in block
$ sho sym offset
  OFFSET = 40580   Hex = 00009E84  Octal = 00000117204

$

$ patch/abs DSA0:[VMS$COMMON.SYS$LDR]SYS$CPU_ROUTINES_1102.EXE


  OpenVMS PATCH Version T8.2-000

%PATCH-I-NOGBL, some or all global symbols not accessible
%PATCH-I-NOLCL, image does not contain local symbols
PATCH>exa 09e84
00009E84:  227F076C
PATCH>exit

 

Once you've verified this, you could consider patching that location to '227F0780' (replace literal 1900. by 1920.) and updating the file:

 

PATCH>exa 9e84
00009E84:  227F076C
PATCH>dep/word .=780
old:    00009E84:  076C
new:    00009E84:  0780

PATCH> update

PATCH>update
%PATCH-I-WRTFIL, updating image file device:[dir]SYS$CPU_ROUTINES_1102.EXE;1
PATCH> Exit

 

Then consider to but the patched SYS$CPUROUTINES_nnnn.EXE into SYS$SPECIFIC:[SYS$LDR], shtudown and power-off your XP1000 and boot it again.

 

Have an OpenVMS Alpha CD to boot from it and delete that patched image, if something had gone wrong...

 

Volker.

Please use plain text.
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 29 of 46 (1,034 Views)

Re: Changes Boot behavior on XP1000 since 2013

I found SRM_CHECK.EXE as part of VMS even for V7.2-1 giving a good listing of the code.

I got the assembler listing of SYS$CPU_ROUTINES_2208.EXE with:

$ set def sys$loadable_images

$ srm_check = "$sys$common:[sysexe]srm_check.exe"

$ define sys$output sys$cpu_routines_2208.lis   ! I didn't know about -output parameter until then

$ srm_check -verbose -dump sys$cpu_routines_2208.exe

$ deassign Sys$output

 

Inside the listing I found the two base years 1900 and 2000 and how they are selected:

 

00000000   A2100000     ldl               R16, (R16)                   # start

00000004   63FF4000     mb            
00000008   63FF4000     mb

.

.

.

00008DC0   A49D0020     ldq              R4, 0x20(R29)           # R4 = 32(R29)
00008DC4   A4620028     ldq              R3, 0x28(R2)              # R3 = 40(R2)

00008DC8   223F07D0     lda               R17, 0x7D0(R31)      # R17 = 2000
00008DCC   225F076C      lda               R18, 0x76C(R31)      # R18 = 1900
00008DD0   A0030000     ldl                R0, (R3)                        # R0 = 1. value for cmple

00008DD4   48861721     sll                 R4, 0x30, R1              # isolate the halfword in R4
00008DD8   48261781     sra               R1, 0x30, R1              #    and put it in R1 giving 2. value for cmple
00008DDC   A21D002C      ldl                R16, 0x2C(R29)
00008DE0   489F9633      zapnot        R4, 0xFC, R19
00008DE4   40010DA0      cmple         R0, R1, R0                   # R0 = (R0 <= R1) ? 1 : 0
00008DE8   4A1F9630      zapnot         R16, 0xFC, R16
00008DEC   44110492      cmoveq       R0, R17, R18             # R18 = R17 if (R0 = 0),  i.e.  R18 = 1900 or 2000
00008DF0   A6FD0038      ldq                R23, 0x38(R29)
00008DF4   A7220020      ldq                R25, 0x20(R2)
00008DF8   40320401      addq            R1, R18, R1                #  R1 = R1 + R18,   i.e.  + 1900 or  2000

 

After that instruction, register R1 seems to have the right year.

 

Changing the instruction

 

00008DCC   225F076C      lda               R18, 0x76C(R31)      # R18 = 1900

 

to

 

00008DCC   225F0780      lda               R18, 0x780(R31)      # R18 = 1920

 

should give the desired workaround.

 

$ dump SYS$CPU_ROUTINES_2208.EXE

shows that the instructions begin at Virtual block number 3 in the EXE-file:

 

Virtual block  number 3 (00000003), 512 (0200) bytes

 6BFA8001 B2110000 47E03400 00000002 2FFE0000 63FF4000 63FF4000 A210000

 

so instruction address 00000000 starts at file position 1024 (x0400).

Please use plain text.
Esteemed Contributor
H.Becker
Posts: 360
Registered: ‎04-09-2009
Message 30 of 46 (1,031 Views)

Re: Changes Boot behavior on XP1000 since 2013

> $ srm_check -verbose -dump sys$cpu_routines_2208.exe


Try $ srm_check -dump  -verbose sys$cpu_routines_2208.exe

and it will show you the VBN where the section starts.

 

Please use plain text.
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 31 of 46 (1,031 Views)

Re: Changes Boot behavior on XP1000 since 2013

> $ srm_check -verbose -dump sys$cpu_routines_2208.exe

 

So the output of SRM_CHECK.EXE depends on the position of the parameters.

Nevertheless calling SRM_CHECK.EXE this way gives you all information you need.

 

Our first try to patch SYS$CPU_ROUTINES_2208.EXE for VMS V7.3-2 was successful.

You have to patch this exe for every VMS version as they show different assembler code.

Please use plain text.
Esteemed Contributor
H.Becker
Posts: 360
Registered: ‎04-09-2009
Message 32 of 46 (1,023 Views)

Re: Changes Boot behavior on XP1000 since 2013

> So the output of SRM_CHECK.EXE depends on the position of the parameters.

 
-dump (and probably others) simply overwrites what was already parsed. -verbose just sets a bit mask in whatever is there. The source code should be at the same location where you found the .exe. Feel free to change it. I did, with some other changes to make it work on Linux.
 
Please use plain text.
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 33 of 46 (951 Views)

Re: Changes Boot behavior on XP1000 since 2013

Tests on our XP1000 with the hwc-year-byte after a "$ set time" command
produce following results:

set time  before   after
year        INIT        INIT

2000        00         00
...
2012        0C         0C
---------------------------
2013        0D         5D
...
2019        13         63
---------------------------
2020        14         00
...
2040        28         14
---------------------------
2041        29         29
...
2044        F0         F0
                FF         FF
          
Changing the code in SYS$CPU_ROUTINES_xxxx.EXE as proposed before results in
a workaround running well from 2013 to 2019. This is only possible because the
after-INIT-year-bytes are greater than EXE$GL_TRANSITION_YEAR, hence base 1900 is taken
which could be corrected to 1920. So two different year-bytes are assigned the same
year.
For the period 2020 to 2039 both hwc-year-bytes are less than EXE$GL_TRANSITION_YEAR.
You have to change this value too to be able to continue working with two different time base years furthermore.
Where does EXE$GL_TRANSITION_YEAR come from? Is it located in SYS$CPU_ROUTINES_xxxx.EXE too and changeable without any side effect for years 2020 to 2039?

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 34 of 46 (945 Views)

Re: Changes Boot behavior on XP1000 since 2013

Michael,

 

are we doing research for HP here ?

 

When do you retire ? Let your successor worry about removing that patch in 2041 ;-)

 

EXE$GL_TRANSITION_YEAR lives in SYS$BASE_IMAGE and has a value of 57. (SDA> EXA EXE$GL_TRANSITION_YEAR). It could be 'patched', but it's not necessary:

 

You could just patch the '2000' being added if HWC-time is <= transition-year to a '2020'

 

00008DC8 223F07D0 lda R17, 0x7D0(R31) # R17 = 2000

 

If you patch x07D0 to x07E4, that code would add 2020, if the HWC-time is less or equal 57. (transition year), so this patch would continue working correctly until 2041, then you could just start using the unpatched image again.

 

Volker.

 

PS: Nevertheless, I would like to 'see' the bad Firmware code posted here, so we could all have a look 

Please use plain text.
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 35 of 46 (942 Views)

Re: Changes Boot behavior on XP1000 since 2013

Volker,

 

in 2020 the hwc returns two possible values:

 

after booting without power_off (reboot): x14

after booting with power_off / INIT:           x00

 

A patch with 2020 instead of 2000 will only work for a boot after power_off (2020 + x00 = 2020).

After a reboot without power_off year would be 2020 + x14 = 2040.

To be able to get the same year for hwc x14 and x00 I have to add two different base times, one in the IF-branch and the other in the ELSE-branch.  Without patching EXE$GL_TRANSITION_TIME to a value between x14 and x00 I only run into the same branch for both hwc values.

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 36 of 46 (937 Views)

Re: Changes Boot behavior on XP1000 since 2013

Michael,

 

now it's getting complicated, right ?

 

For years 2020 until 2039, the algorithm should be:

 

if hwc_year GEQ 20. then add 2000. else add 2020.

 

Instead of patching EXE$GL_TRANSITION_YEAR in SYS$BASE_IMAGE.EXE in 2020, I would vote for changing the instruction stream to load a constant value of 0x14 into R0

 

00008DD0: A0030000   LDL R0, (R3)        ! load value of EXE$GL_TRANSITION_YEAR into R0

 

replace with

 

00008DD0: 201F0014   LDA R0, 0x14(R31)  ! load constant of 20. into R0 as transition year

 

Volker.

Please use plain text.
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 37 of 46 (914 Views)

Re: Changes Boot behavior on XP1000 since 2013

Volker,

 

good proposal, better than  patching a second image (SYS$BASE_IMAGE.EXE) and  possible side effects will be minimized too.

Whether HP will publish something about the XP1000 firmware here?

Please use plain text.
Occasional Visitor
Stephane_Boneff
Posts: 2
Registered: ‎04-03-2013
Message 38 of 46 (806 Views)

Re: Changes Boot behavior on XP1000 since 2013

Hello,

 

I discovered that bug yesterday : on a Alphaserver 400, with a new TOY chip, the AS400 still ask

date and time after a power shutdown.

 

(I made change the TOY thinking the battery was empty !)

 

This appeared only with date of 2013 (I try 2012 and the boot was normal).

 

 

The AS is running OpenVMS 6.2.

 

Version of firmware :

SRM Console: X5.0-30

ARC Console: 4.37

PALcode:     VMS PALcode X5.48-107, OSF PALcode X1.35-76

Serial Rom:  V4.6

Diag Rom:    V1.7

 

The Customer has 3 other AS400, I hope they are not concerned by this bug.

 

I don't know there firmware version.

 

 

hope there is a simple solution.....

 

 

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 39 of 46 (798 Views)

Re: Changes Boot behavior on XP1000 since 2013

Stephane,

 

the ANALYZE/SYSTEM SDA> CLUE CONFIG command may show the SRM console version on a running system.

 

You should assume, that the other AlphaServer 400 systens are affected by the SAME problem.

 

There is no 'simple solution'. Some workarounds are described in previous entries in this thread.

 

If you can, please escalate your problem to HP OpenVMS support.

 

Volker.

Please use plain text.
Occasional Visitor
Stephane_Boneff
Posts: 2
Registered: ‎04-03-2013
Message 40 of 46 (781 Views)

Re: Changes Boot behavior on XP1000 since 2013

hello Volker,

 

Thank you for your answer.

 

I have there SRM version for the other alpha :

6.4-2

6.2-2

7.2-1

 

These machines are not easly to shutdown (connected to industrial system) so the test was not performed yet.

 

 

Unfortunately, we don't have a support contract with HP anymore but with an local compagny.

They are looking for suitable firmwares.

 

 

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 41 of 46 (780 Views)

Re: Changes Boot behavior on XP1000 since 2013

Stephane,

 

for XP1000: Firmware V5.9-1 was the last firmware release

 

So your 'other Alphas' are NOT XP1000 systems and are most likely NOT affected by this problem.

 

Volker.

Please use plain text.
Occasional Visitor
Jerry_Clark
Posts: 1
Registered: ‎04-12-2013
Message 42 of 46 (761 Views)

Re: Changes Boot behavior on XP1000 since 2013

For everyone's information...

You can add AS2100 5/250 and AS2100 5/300 to the list.

And we all thought Y2K was long behind us!
Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 43 of 46 (759 Views)

Re: Changes Boot behavior on XP1000 since 2013

Jerry,

 

could you also please report the SRM Firmware versions of the affected systems.

 

Thanks,

 

Volker.

Please use plain text.
Occasional Visitor
Jerry-Clark
Posts: 1
Registered: ‎04-12-2013
Message 44 of 46 (740 Views)

Re: Changes Boot behavior on XP1000 since 2013

Volker,

 

Both (clustered) systems are running OpenVMS 7.2-1.

 

on the 5/300:

Pal Code: 1.20-3

Console Version: V5.3-6

 

on the 5/250:

Pal Code: 1.20-3

Console Version: V5.3-14

 

Jerry

Please use plain text.
Occasional Advisor
Edward Miller_1
Posts: 6
Registered: ‎02-23-2005
Message 45 of 46 (625 Views)

Re: Changes Boot behavior on XP1000 since 2013

A warning for others: the clock error diagnosed in this discussion may result in
a system HANG during boot, rather than the prompt for date-time. We experienced
this (on an AS4100 running not up-to-date VMS 8.3). It is pretty clear (though
we have not proved it by demonstration) that the hang resulted because we had not
installed an update to EXEC_INIT.EXE which corrects a hang during boot in circumstances
like these (clock confusion). In any case, the fix is the same:
patch SYS$CPU_ROUTINES_xxxx.EXE as described in this discussion.
For details see the discussion in this forum under VMS System Management:
"Formerly reliable V8.3 AS4100 boot now hangs"

-- Ed Miller

Please use plain text.
Occasional Advisor
alphacat
Posts: 17
Registered: ‎08-27-2011
Message 46 of 46 (435 Views)

Re: Changes Boot behavior on XP1000 since 2013

As I think it unreasonable to interfere into VMS code,

I am using the best Volker's solution :

>>> d -b toy:9 0D         (0E in the next year)

This line is inserted into nvram script,

so every time after power on I have to type  

>>> nvram

prior to boot. It is a pity that nvram is not executed automatically

at power on as it should do by specifications.

Perhaps this is another bug of the firmware 5.9-1.

 

Vladimir

 

 

Please use plain text.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation