set write bit 0 7f9 c! reset stop bit 80 7fb c! set kick start 0 7f8 c! reset write bit wait for two seconds 80 7f8 c! set write bit 0 7fb c! reset kick start 0 7f9 c! set dummy time and date 0 7fa c! (if necessary) 0 7fb c! 4 7fc c! 11 7fd c! 1 7fe c! 96 7ff c! 0 7f8 c! reset write bit Other more arcane methods for modifying the IDPROM mkp and mkpl are not the only way to modify the IDPROM. Before I discovered these commands, I used to use procedures like the ones below. The material in this section assumes that you have access to the OpenBoot PROM manual which is part of the Solaris 2.x Answerbook. You can use the OpenBoot monitor to find the virtual address of the NVRAM. The basic steps are: 1. cd to the eeprom device (you can find its exact name via show-devs) 2. execute .attributes or .properties depending upon whether you have V2 or V3 of the OpenBoot PROM. 3. execute device-end followed by reset For example ok show-devs ... /obio/eeprom@0,200000 ... ok cd /obio/eeprom@0,200000 ok .attributes address: ffee9000 ... ok device-end ok reset >From this point, you can modify and look at the NVRAM by using the c!, dump,and c? commands in the OpenBoot PROM. You can also get the virtual address of the NVRAM by looking at the output of /usr/etc/devinfo -vp under Sun OS 4.1.x or /usr/sbin/prtconf -vp under Solaris 2.x. On sun4c machines, the IDPROM starts at offset 0x7d8 from the start of the NVRAM. On sun4m, sun4d, and sun4u machines the offset is 0x1fd8. >From here one can also find the physical address of the NVRAM using pgmap?. In the above example, if we type ffee9000 pgmap? at the OpenBoot prompt, we get a few lines of output, one of which is Physical: 0.7120.0000 which means on this machine the physical address is 71200000 in address space 0. You can also use map-page to map the physical address of the page containing the IDPROM to virtual address 0. To do this you need to know the physical address of the NVRAM. You can find it as above or just use the following table: machine type address space arch -k SS1, SS1+, SS2, ELC, IPC, IPX, SLC 02000000 obio sun4c Classic, LX, SS5, SS4, Voyager 71200000 0 sun4m SS10, SS20, 6x0/MP f1200000 f sun4m SS1000 00280000 f sun4d For the sun4m and sun4d machines, the page size is 4kB (0x1000) so the simplest thing to do is map the second page of the NVRAM. This is because we're using map-page and it only maps one page at a time. e.g. Modify the hostid of an IPX to be 57c0ffee and the ethernet address to be 8:0:20:c0:ff:ee 02000000 obio 0 map-page 1 7d8 c! 57 7d9 c! 08 7da c! 0 7db c! 20 7dc c! c0 7dd c! ff 7de c! ee 7df c! 57 7e0 c! 0 7e1 c! 0 7e2 c! 0 7e3 c! c0 7e4 c! ff 7e5 c! ee 7e6 c! 29 7e7 c! e.g. to modify the hostid of an SS10 to be 72c0ffee and the ethernet address to be 08:00:20:c0:ff:ee, do the following f1201000 f 0 map-page 01 fd8 c! 72 fd9 c! 08 fda c! 0 fdb c! 20 fdc c! c0 fdd c! ff fde c! ee fdf c! 72 fe0 c! 0 fe1 c! 0 fe2 c! 0 fe3 c! c0 fe4 c! ff fe5 c! ee fe6 c! 29 fe7 c! Note that we added 0x1000 to the physical address in the above table, as explained above. The hostid on Solaris 2.5 x86 Intel processor machines don't have an IDPROM. Sun uses a different mechanism to generate the hostid. When the operating system is initially installed a pseudo-random hostid is generated. It appears that this pseudo-randomly generated hostid will always be between 1 and 3b9aca00. The hostid is based on eight bytes of serialisation information in the kernel module /kernel/misc/sysinit. This is in contrast to the situation on SPARC machines where the hostid is based on the IDPROM. /kernel/misc/sysinit contains code which initialises the variable hw_serial in the kernel based on the serialisation information. On both SPARC and x86 versions of Solaris 2.5, hw_serial stores the hostid as a decimal C string. Other than the eight bytes of serialisation information the /kernel/misc/sysinit files do not differ between machines. Four of the serialisation bytes depend upon the other four bytes, so the hostid is somewhat tamper resistant. If the serialisation information is tampered with carelessly or the sysinit module fails to load for some other reason, the hostid of the machine will be 0. A little more obfuscation is done in the code, i.e. hw_serial is not referenced directly in the module, but indirectly via the pointer _hs1107. This means that if you need to have two machines with the same hostid for some reason (say, to have a backup server with the same hostid in case your primary server malfunctions), you can just copy the /kernel/misc/sysinit file from one machine to another. Moreover, it seems that initialising hw_serial is the only function performed by the sysinit module. Hence, it is a simple matter to replace /kernel/misc/sysinit yielding a machine with whatever hostid one wants, by compiling a simple C program for a loadable kernel module which sets hw_serial to the desired value. C code for a generic replacement sysinit module is included in change sun hostid which is available from the sites listed near the beginning of this document. Replacing part of the operating system is probably not the best way to achieve this effect. In general, I'd recommend using one of the other modules in change sun hostid as there is less risk of damaging things and rendering the system unbootable, but a few people have asked for this. The NVRAM in sun4 architecture machines The sun4 machines (e.g. Sun 4/1xx, 4/2xx, 4/3xx, etc.) also have M48T02 chips. These chips do not store the hostid and ethernet address, which are in an actual PROM, but they do keep track of the time of day and the system configuration information. Replacing the NVRAM chip is a relatively simple matter, the only trick is to set the appropriate values in the Sun PROM monitor using the q command then boot the operating system to kick-start the clock. You can use the table for the Sun 3/80 to set the values in the old Sun PROM monitor. The only significant difference is that normal/diagnostic boot is controlled by a physical switch instead of the byte at location 0x70b. See the Sun Hardware Reference (referred to above), your machine documentation, or the Sun FE Handbook if you need more information on the Sun PROM monitor. ---------------------------------------------------------------------------- Credits I'd like to thank the following people who have helped make this a better document. If I've left anyone off this list who should be on it please drop me a note and I'll add the name to the list. * Kevin Murty for the use of an SS1000 for testing * simonallen@cix.compulink.co.uk for the kick-start information, information on the Sun OS 4.1 clock bug on the 3/80, a U.K. source of NVRAM chips. * Michael Firth for a U.K. source of NVRAM chips. * dowdy@cs.colorado.edu (Stephen Dowdy) * drzob@vectrex.login.qc.ca (Denis Solaro) * coughlin@cfa0.harvard.edu (Michael Coughlin) for numerous suggestions and bits of information. * sameer@c2.org * Kenji Oshima for the GIF image of a M48T02 and a source for replacement NVRAM chips in Japan. * eberin@xsvr1.cup.hp.com (Eddie Berin) * Marek Jedryszek * Andy Michael * Bernd Wagner * Lonnie Borntreger <67goat@exchange.wcc.att.com> * Jay York * James Lin * Werner Lappessen -- Mark Henderson -- markh@wimsey.bc.ca, henderso@netcom.com, mch@squirrel.com ViaCrypt PGP Key Fingerprint: 21 F6 AF 2B 6A 8A 0B E1 A1 2A 2A 06 4A D5 92 46 http://www.squirrel.com/squirrel/ - change-sun-hostid, unstrip for Solaris, computer security, TECO, FGMP, Sun NVRAM/hostid FAQ, Wimsey crypto archive