1 #ifndef __SPARC_OPENPROM_H 2 #define __SPARC_OPENPROM_H 3 4 /* openprom.h: Prom structures and defines for access to the OPENBOOT 5 prom routines and data areas. 6 7 Copyright (C) 1994 David S. Miller (davem@caip.rutgers.edu) 8 */ 9 10 /* In the v0 interface of the openboot prom we could traverse a nice 11 little list structure to figure out where in vm-space the prom had 12 mapped itself and how much space it was taking up. In the v2 prom 13 interface we have to rely on 'magic' values. :-( Most of the machines 14 I have checked on have the prom mapped here all the time though. 15 */ 16 #define LINUX_OPPROM_BEGVM 0xffd00000 17 #define LINUX_OPPROM_ENDVM 0xfff00000 18 19 #define LINUX_OPPROM_MAGIC 0x10010407 20 21 /* The device functions structure for the v0 prom. Nice and neat, open, 22 close, read & write divvied up between net + block + char devices. We 23 also have a seek routine only usable for block devices. The divide 24 and conquer strategy of this struct becomes unnecessary for v2. 25 26 V0 device names are limited to two characters, 'sd' for scsi-disk, 27 'le' for local-ethernet, etc. Note that it is technically possible 28 to boot a kernel off of a tape drive and use the tape as the root 29 partition! In order to do this you have to have 'magic' formatted 30 tapes from Sun supposedly :-) 31 */ 32 33 struct linux_dev_v0_funcs { 34 int (*v0_devopen)(char *device_str); 35 int (*v0_devclose)(int dev_desc); 36 int (*v0_rdblkdev)(int dev_desc, int num_blks, int blk_st, char* buf); 37 int (*v0_wrblkdev)(int dev_desc, int num_blks, int blk_st, char* buf); 38 int (*v0_wrnetdev)(int dev_desc, int num_bytes, char* buf); 39 int (*v0_rdnetdev)(int dev_desc, int num_bytes, char* buf); 40 int (*v0_rdchardev)(int dev_desc, int num_bytes, int dummy, char* buf); 41 int (*v0_wrchardev)(int dev_desc, int num_bytes, int dummy, char* buf); 42 int (*v0_seekdev)(int dev_desc, long logical_offst, int from); 43 }; 44 45 /* The OpenBoot Prom device operations for version-2 interfaces are both 46 good and bad. They now allow you to address ANY device whatsoever 47 that is in the machine via these funny "device paths". They look like 48 this: 49 50 "/sbus/esp@0,0xf004002c/sd@3,1" 51 52 You can basically reference any device on the machine this way, and 53 you pass this string to the v2 dev_ops. Producing these strings all 54 the time can be a pain in the rear after a while. Why v2 has memory 55 allocations in here are beyond me. Perhaps they figure that if you 56 are going to use only the prom's device drivers then your memory 57 management is either non-existent or pretty sad. :-) 58 */ 59 60 struct linux_dev_v2_funcs { 61 int (*v2_aieee)(int d); /* figure this out later... */ 62 63 /* "dumb" prom memory management routines, probably 64 only safe to use for mapping device address spaces... 65 */ 66 67 char* (*v2_dumb_mem_alloc)(char* va, unsigned sz); 68 void (*v2_dumb_mem_free)(char* va, unsigned sz); 69 70 /* "dumb" mmap() munmap(), copy on write? what's that? */ 71 char* (*v2_dumb_mmap)(char* virta, int asi, unsigned prot, unsigned sz); 72 void (*v2_dumb_munmap)(char* virta, unsigned size); 73 74 /* Basic Operations, self-explanatory */ 75 int (*v2_dev_open)(char *devpath); 76 void (*v2_dev_close)(int d); 77 int (*v2_dev_read)(int d, char* buf, int nbytes); 78 int (*v2_dev_write)(int d, char* buf, int nbytes); 79 void (*v2_dev_seek)(int d, int hi, int lo); 80 81 /* huh? */ 82 void (*v2_wheee2)(void); 83 void (*v2_wheee3)(void); 84 }; 85 86 /* Just like the device ops, they slightly screwed up the mem-list 87 from v0 to v2. Probably easier on the prom-writer dude, sucks for 88 us though. See above comment about prom-vm mapped address space 89 magic numbers. :-( 90 */ 91 92 struct linux_mlist_v0 { 93 struct linux_mlist_v0 *theres_more; 94 char* start_adr; 95 unsigned num_bytes; 96 }; 97 98 /* The linux_mlist_v0's are pointer by this structure. One list 99 per description. This means one list for total physical memory, 100 one for prom's address mapping, and one for physical mem left after 101 the kernel is loaded. 102 */ 103 struct linux_mem_v0 { 104 struct linux_mlist_v0 **v0_totphys; /* all of physical */ 105 struct linux_mlist_v0 **v0_prommap; /* addresses map'd by prom */ 106 struct linux_mlist_v0 **v0_available; /* what phys. is left over */ 107 }; 108 109 /* Arguments sent to the kernel from the boot prompt. */ 110 111 struct linux_arguments_v0 { 112 char *argv[8]; /* argv format for boot string */ 113 char args[100]; /* string space */ 114 char boot_dev[2]; /* e.g., "sd" for `b sd(...' */ 115 int boot_dev_ctrl; /* controller # */ 116 int boot_dev_unit; /* unit # */ 117 int dev_partition; /* partition # */ 118 char *kernel_file_name; /* kernel to boot, e.g., "vmunix" */ 119 void *aieee1; /* give me some time :> */ 120 }; 121 122 /* Prom version-2 gives us the raw strings for boot arguments and 123 boot device path. We also get the stdin and stdout file pseudo 124 descriptors for use with the mungy v2 device functions. 125 */ 126 struct linux_bootargs_v2 { 127 char **bootpath; /* V2: Path to boot device */ 128 char **bootargs; /* V2: Boot args */ 129 int *fd_stdin; /* V2: Stdin descriptor */ 130 int *fd_stdout; /* V2: Stdout descriptor */ 131 }; 132 133 /* This is the actual Prom Vector from which everything else is accessed 134 via struct and function pointers, etc. The prom when it loads us into 135 memory plops a pointer to this master structure in register %o0 before 136 it jumps to the kernel start address. I will update this soon to cover 137 the v3 semantics (cpu_start, cpu_stop and other SMP fun things). :-) 138 */ 139 struct linux_romvec { 140 /* Version numbers. */ 141 unsigned int pv_magic_cookie; /* Magic Mushroom... */ 142 unsigned int pv_romvers; /* iface vers (0, 2, or 3) */ 143 unsigned int pv_plugin_revision; /* revision relative to above vers */ 144 unsigned int pv_printrev; /* print revision */ 145 146 /* Version 0 memory descriptors (see below). */ 147 struct linux_mem_v0 pv_v0mem; /* V0: Memory description lists. */ 148 149 /* Node operations (see below). */ 150 struct linux_nodeops *pv_nodeops; /* node functions, gets device data */ 151 152 char **pv_bootstr; /* Boot command, eg sd(0,0,0)vmunix */ 153 154 struct linux_dev_v0_funcs pv_v0devops; /* V0: device ops */ 155 156 /* 157 * PROMDEV_* cookies. I fear these may vanish in lieu of fd0/fd1 158 * (see below) in future PROMs, but for now they work fine. 159 */ 160 char *pv_stdin; /* stdin cookie */ 161 char *pv_stdout; /* stdout cookie */ 162 #define PROMDEV_KBD 0 /* input from keyboard */ 163 #define PROMDEV_SCREEN 0 /* output to screen */ 164 #define PROMDEV_TTYA 1 /* in/out to ttya */ 165 #define PROMDEV_TTYB 2 /* in/out to ttyb */ 166 167 /* Blocking getchar/putchar. NOT REENTRANT! (grr) */ 168 int (*pv_getchar)(void); 169 void (*pv_putchar)(int ch); 170 171 /* Non-blocking variants that return -1 on error. */ 172 int (*pv_nbgetchar)(void); 173 int (*pv_nbputchar)(int ch); 174 175 /* Put counted string (can be very slow). */ 176 void (*pv_putstr)(char *str, int len); 177 178 /* Miscellany. */ 179 void (*pv_reboot)(char *bootstr); 180 void (*pv_printf)(const char *fmt, ...); 181 void (*pv_abort)(void); /* BREAK key abort */ 182 int *pv_ticks; /* milliseconds since last reset */ 183 void (*pv_halt)(void); /* End the show */ 184 void (**pv_synchook)(void); /* "sync" ptr to function */ 185 186 /* 187 * This eval's a FORTH string. Unfortunately, its interface 188 * changed between V0 and V2, which gave us much pain. 189 */ 190 union { 191 void (*v0_eval)(int len, char *str); 192 void (*v2_eval)(char *str); 193 } pv_fortheval; 194 195 struct linux_arguments_v0 **pv_v0bootargs; /* V0: Boot args */ 196 197 /* Extract Ethernet address from network device. */ 198 unsigned int (*pv_enaddr)(int d, char *enaddr); 199 200 struct linux_bootargs_v2 pv_v2bootargs; /* V2: Boot args+std-in/out */ 201 struct linux_dev_v2_funcs pv_v2devops; /* V2: device operations */ 202 203 int whatzthis[15]; /* huh? */ 204 205 /* 206 * The following is machine-dependent. 207 * 208 * The sun4c needs a PROM function to set a PMEG for another 209 * context, so that the kernel can map itself in all contexts. 210 * It is not possible simply to set the context register, because 211 * contexts 1 through N may have invalid translations for the 212 * current program counter. The hardware has a mode in which 213 * all memory references go to the PROM, so the PROM can do it 214 * easily. 215 */ 216 void (*pv_setctxt)(int ctxt, char* va, int pmeg); 217 218 /* Prom version 3 Multiprocessor routines. This stuff is crazy. 219 * No joke. Calling these when there is only one cpu probably 220 * crashes the machine, have to test this. :-) 221 */ 222 223 /* v3_cpustart() will start the cpu 'whichcpu' in mmu-context 224 * 'thiscontext' executing at address 'prog_counter' 225 * 226 * XXX Have to figure out what 'cancontext' means. 227 */ 228 229 int (*v3_cpustart)(unsigned int whichcpu, int cancontext, 230 int thiscontext, char* prog_counter); 231 232 /* v3_cpustop() will cause cpu 'whichcpu' to stop executing 233 * until a resume cpu call is made. 234 */ 235 236 int (*v3_cpustop)(unsigned int whichcpu); 237 238 /* v3_cpuidle() will idle cpu 'whichcpu' until a stop or 239 * resume cpu call is made. 240 */ 241 242 int (*v3_cpuidle)(unsigned int whichcpu); 243 244 /* v3_cpuresume() will resume processor 'whichcpu' executing 245 * starting with whatever 'pc' and 'npc' were left at the 246 * last 'idle' or 'stop' call. 247 */ 248 249 int (*v3_cpuresume)(unsigned int whichcpu); 250 251 }; 252 253 /* 254 * In addition to the global stuff defined in the PROM vectors above, 255 * the PROM has quite a collection of `nodes'. A node is described by 256 * an integer---these seem to be internal pointers, actually---and the 257 * nodes are arranged into an N-ary tree. Each node implements a fixed 258 * set of functions, as described below. The first two deal with the tree 259 * structure, allowing traversals in either breadth- or depth-first fashion. 260 * The rest deal with `properties'. 261 * 262 * A node property is simply a name/value pair. The names are C strings 263 * (NUL-terminated); the values are arbitrary byte strings (counted strings). 264 * Many values are really just C strings. Sometimes these are NUL-terminated, 265 * sometimes not, depending on the the interface version; v0 seems to 266 * terminate and v2 not. Many others are simply integers stored as four 267 * bytes in machine order: you just get them and go. The third popular 268 * format is an `address', which is made up of one or more sets of three 269 * integers as defined below. 270 * 271 * One uses these functions to traverse the device tree to see what devices 272 * this machine has attached to it. 273 * 274 * N.B.: for the `next' functions, next(0) = first, and next(last) = 0. 275 * Whoever designed this part had good taste. On the other hand, these 276 * operation vectors are global, rather than per-node, yet the pointers 277 * are not in the openprom vectors but rather found by indirection from 278 * there. So the taste balances out. 279 */ 280 struct linux_prom_addr { 281 int oa_space; /* address space (may be relative) */ 282 unsigned int oa_base; /* address within space */ 283 unsigned int oa_size; /* extent (number of bytes) */ 284 }; 285 286 struct linux_nodeops { 287 /* 288 * Tree traversal. 289 */ 290 int (*no_nextnode)(int node); /* next(node) */ 291 int (*no_child)(int node); /* first child */ 292 293 /* 294 * Property functions. Proper use of getprop requires calling 295 * proplen first to make sure it fits. Kind of a pain, but no 296 * doubt more convenient for the PROM coder. 297 */ 298 int (*no_proplen)(int node, char* name); 299 int (*no_getprop)(int node, char* name, char* val); 300 int (*no_setprop)(int node, char* name, char* val, int len); 301 char* (*no_nextprop)(int node, char* name); 302 }; 303 304 #endif /* !(__SPARC_OPENPROM_H) */