[3341] in testers
CNBOOT ultra support
daemon@ATHENA.MIT.EDU (John Hawkinson)
Fri Sep 26 05:49:10 1997
Date: Fri, 26 Sep 1997 05:49:02 -0400 (EDT)
To: Michal N Lusztig <miki@MIT.EDU>
Cc: athena-install@MIT.EDU, sol24@MIT.EDU, Charles Hannum <mycroft@MIT.EDU>,
Matt Braun <mhbraun@MIT.EDU>
From: John Hawkinson <jhawk@MIT.EDU>
| From the Sun engineers in Toronto we have that the PROM has some
| problems making it impossible to work with the CNBOOT program ??
| They are supposed to fix it.. but ...
Well, I spent quite a lot of time Thursday-into-Friday making CNBOOT
work correctly on the Ultra. There were a number of problems, but they
all seem to have been resolved.
People who were especially helpful were Matt Braun, Charles Hannum,
Greg Hudson, and Karl Ramm.
There were three major problems with the 5.5 CNBOOT binary as
distributed by OPCOM (SUN Canada):
1) It was a v7 instruction set binary and not a v9
and didn't seem to boot properly on the Ultra.
2) It assumes that it can walk the device tree
for a device called "le" and doesn't handle not
finding that device very well. The Ultra in Greg's
office has a SUNW,hme interface rather than an le
interface. (That's Happy Meal Ethernet, FYI).
3) The PROM interface for attributes/properties changed
from OpenBOOT 2.x to OpenBOOT 3.x (OpenFirmware).
Getting CNBOOT to work took hours of disassembling rom monitor forth
and assembler, as well as kernel traipsing. Very un-fun, but
ultimately rewarding.
Documentation on the OpenBoot ROM stuff is in the "IEEE p1275 core
document". You probably should order a copy from IEEE. I made use of a
draft copy that may have come from ftp://playground.sun.com/pub/p1275.
This is beyond Sun's OpenBoot Command Reference 3.x, which is pretty
much orthogonal.
All mods to CNBOOT were isolated to stand/lib/fs/nfs_inet.
I've attached them below, since they're not very incriminating.
I assume I get zero points for style, but you're welcome (encouraged!)
to clean them up before actually using them or submitting them to Sun.
I should note that I haven't been using CNBOOT off of a floppy disk,
so I'm not certain whether that works. Since CNBOOT was changing under
me frequently, I netbooted it via tftp, i.e.:
boot net:18.70.0.62,cnboot.4u,18.177.0.55,18.177.0.1
Some additional twiddling may be required to make it work on a floppy,
including perhaps messing around with the boot blocks. Note that the
Ultra PROM, unlike the SS5/SS4 PROMs, is capable of relocating and executing
ELF code all by it's lonesome without any assistance.
Here come the patches. It's worth noting that none of these patches
are awful deep or complicated. In particular, anyone could implement
workable versions by just patching stuff by hand in adb (you would
have trouble with the le/hme fallback, but could presumably just pick
one or the other).
In network_open.c, I modify opcom_build_path to return a success indicator,
and make it check the value of prom_findnode_by_name() against NULL.
It took quite a long time to for Charles and I to track down this problem
because single-stepping from C code into Forth code is pretty non-intuitive.
Anyhow, opcom_build_path() now lets it's caller (network_open()) know if
it fails. network_open() now tries opcom_build_path() for "le" and then
"SUNW,hme". It should be relatively easy to add any other interfaces that
might arise.
The call to opcom_get_defaults() is commented out because it does not
work properly if CNBOOT is loaded off of a medium that does not support
seeking (e.g. tftp). The better solution is to hardcode the values that
it presently reads from a file in such a way as they are patchable.
If you just boot this CNBOOT as-is you'll get "0.0.0.0 ask" as the default
for all parameters, which is fine for testing, but suboptimal for deployment.
As for mount.c, OpenBOOT 3.x replaced the concept of "attributes" in the device
tree with "properties". The FORTH code is simply updated to new-speak. New-speak
is not compatible with old-speak, as I'm sure everyone knows. So this version
won't work right on an ss5 or ss4. It'd be pretty easy to fix this, but I don't
know if you could produce a cnboot ELF executable that worked right on both
kinds of machines. You could certainly make a "fat" binary, I suppose...
*** network_open.c 1997/09/26 02:24:40 1.1
--- network_open.c 1997/09/26 02:49:01
***************
*** 68,74 ****
static int opcom_parse_defaults(char *buf);
static long inet_network(char *);
static void opcom_get_ip(struct opcom_in_addr *ip, char *s);
! static void opcom_build_path(char *buf, char *name);
static void opcom_move(char *dst, char *src);
static int opcom_getname(dnode_t node, char *buf);
static void opcom_get_router_address(struct opcom_in_addr *ip,
--- 68,74 ----
static int opcom_parse_defaults(char *buf);
static long inet_network(char *);
static void opcom_get_ip(struct opcom_in_addr *ip, char *s);
! static int opcom_build_path(char *buf, char *name);
static void opcom_move(char *dst, char *src);
static int opcom_getname(dnode_t node, char *buf);
static void opcom_get_router_address(struct opcom_in_addr *ip,
***************
*** 121,127 ****
* who else would load a diskless boot program? ;^)
*/
#ifdef OPCOM
! opcom_build_path(le_path, "le");
#ifdef OPCOM_DEBUG
printf("network_open: le_path = %s\n", le_path);
printf("network_open: str = %s\n", str);
--- 121,130 ----
* who else would load a diskless boot program? ;^)
*/
#ifdef OPCOM
! opcom_build_path(le_path, "le") &&
! opcom_build_path(le_path, "SUNW,hme") &&
! (prom_panic("Could not find network device in device tree.\n"),0);
!
#ifdef OPCOM_DEBUG
printf("network_open: le_path = %s\n", le_path);
printf("network_open: str = %s\n", str);
***************
*** 158,165 ****
--- 161,170 ----
if (prom_getmacaddr(bootd.handle, (caddr_t) &sainet.sain_myether) != 0)
prom_panic("Could not obtain ethernet address for client.\n");
+ #if 0
/* Get the defaults file */
opcom_get_defaults();
+ #endif
/* Parse */
if (opcom_parse_defaults(defaults_buf) == OPCOM_NO_DEFAULTS)
***************
*** 428,434 ****
return;
}
! static void
opcom_build_path(char *buf, char *name)
{
dnode_t curnode;
--- 433,439 ----
return;
}
! static int
opcom_build_path(char *buf, char *name)
{
dnode_t curnode;
***************
*** 447,452 ****
--- 452,463 ----
curnode = prom_findnode_byname(prom_rootnode(), name, stk);
prom_stack_fini(stk);
+ if (curnode == NULL) {
+ printf("opcom_build_path: NULL curnode for device %s\n",
+ name);
+ return -1;
+ }
+
while(curnode != prom_rootnode()) {
#ifdef OPCOM_DEBUG
***************
*** 477,482 ****
--- 488,494 ----
prom_strcpy(buf, path_begin);
bkmem_free(full_path, OBP_MAXDEVNAME*10);
+ return 0;
}
static void
*** mount.c 1997/09/26 09:13:10 1.1
--- mount.c 1997/09/26 09:11:37
***************
*** 65,70 ****
--- 65,71 ----
register int resp_wait; /* how long to wait for a resp */
#ifdef OPCOM
char *mkdev;
+ #if 0 /* OBP 2.x */
char *mkdevfmt =
" \" /\" find-device "
"new-device "
***************
*** 77,82 ****
--- 78,97 ----
" \" %s\" xdrstring \" domainname\" attribute "
"finish-device "
;
+ #else /* OBP 3.x (ultra) */
+ char *mkdevfmt =
+ " \" /\" find-device "
+ "new-device "
+ " \" cnbdrv\" device-name "
+ " h# %x encode-int \" mip\" property "
+ " h# %x encode-int \" hip\" property "
+ " h# %x encode-int \" sip\" property "
+ " h# %x encode-int \" nip\" property "
+ " \" %s\" encode-string \" hostname\" property "
+ " \" %s\" encode-string \" domainname\" property "
+ "finish-device "
+ ;
+ #endif
#endif
if (network_up == 0) {
Aside from those changes, everything is pretty much free and clear.
Greg untarred your 2.5.1 root from the bootkit locker into the
tree you made for me on solar (/var/ops/new.hawks).
We had to make some minor changes to things. For instance etc/system
needed to have "set zs:zsmax=8" in order for kernel to correctly
probe all the UARTS and not panic mid-way.
Enjoy!
--jhawk
ps: Oh yes, before I tried a v9-SPARC CNBOOT, we updated the flash
PROM in the ultra to the latest rev by applying sun patch 104288-03.
It's not clear that this was necessary, but since one of the bug-id's
it fixes is:
Bugid 1252098: Booting from floppy disk now works.
it seemed prudent...
pps: You can tftpboot the "cnboot.4u" binary from bobbi-harlow.mit.edu
to get this whole process started.
