rhyde@ucrmath.ucr.edu (randy hyde) (03/25/91)
I copied the instruction sequence from Bruce's monitor *exactly* (the one which initializes the ICU to generate the refresh clock) and executed it from RAM under control of the monitor. It crashed the system. I ran this code from location x'10000. Does this sequence flake out the RAM (I.e., swap the EPROMs back in)? On another plane, if anyone knows of a good reference that will explain user/system memory spaces and how the two talk to each other (e.g., how do processes and the OS communicate?), I'd sure appreciate a pointer. I do not relish the idea of experimenting with code until I get something to work. Is there an NS/TI32532 programming manual? I have the hardware manual. But my programming manual is just for Series 32000 (written in the days of the 32016) and it doesn't discuss some of the newer features like direct exceptions, etc. *** Randy Hyde
culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (03/26/91)
Hi Randy, > According to NS, if a dbugger patches in a BPT instruction (meaning you've > got self-modifying code) you need to invalidate the cache and "serialize" > the instruction stream. Come to think of it, I never explicitly invalidated the cache in the monitor where it inserts BPT's. It does write both PTB's, though, and maybe that has the same effect. Never noticed a problem. Since I originally used the monitor on a 32016, I could have overlooked a few of the 32532 details. > Does Minix/532 use the SVC instruction to call the operating system? Yes. > Is SVC the only way to call some system routines at who knows where in > system RAM? I think it is the only obvious way. You could, of course, use BPT, divide-by-zero, or some illegal opcode. You need something which causes an exception to change the memory mapping, privilege level, etc. > I copied the instruction sequence from Bruce's monitor *exactly* (the one > which initializes the ICU to generate the refresh clock) and executed it from > RAM under control of the monitor. It crashed the system. Did you execute the code which initializes the memory parity? It writes every location in the DRAM, which would have wiped out your program. When I debugged the monitor, I also ran it in DRAM. However, I inserted a "br _main" at the beginning so it would skip the memory initialization. > On another plane, if anyone knows of a good reference that will explain > user/system memory spaces and how the two talk to each other (e.g., how do > processes and the OS communicate?), I'd sure appreciate a pointer. I do not > relish the idea of experimenting with code until I get something to work. > Is there an NS/TI32532 programming manual? I have the hardware manual. > But my programming manual is just for Series 32000 (written in the days of the > 32016) and it doesn't discuss some of the newer features like direct exceptions, > etc. I have "Series 32000 Microprocessors Databook Rev.1" and the old 32016 programming manual. Between the two of them, I think you get a complete description of the 32532. However, something more tutorial might be nice to have. Bruce
rhyde@ucrmath.ucr.edu (randy hyde) (03/27/91)
>>>>> > I copied the instruction sequence from Bruce's monitor *exactly* (the one > which initializes the ICU to generate the refresh clock) and executed it from > RAM under control of the monitor. It crashed the system. Did you execute the code which initializes the memory parity? It writes every location in the DRAM, which would have wiped out your program. When I debugged the monitor, I also ran it in DRAM. However, I inserted a "br _main" at the beginning so it would skip the memory initialization. <<<<< It turned out to be one of those very stupid mistakes you're always so embarrassed to admit to. I copied your code *exactly*. Part of the sequence was to write an x'ff to the 32202 output port. This swapped out RAM and swapped in EPROM at address zero. You're code worked because the same data appeared at the same locations in RAM and EPROM, mine died because once the EPROM got swapped in, who knows what was happening at address 30000h? I now have some conditional assembly directives which assemble the code two ways, one for debugging in RAM, one for EPROM. Both work like a charm at this point. I wrote my own debugger/monitor about eight years ago (for the 16032). I've just managed to port it to the PC532 and I'm enhancing it to take advantage of the 32532. The direct exception mode on the 32532 is *great*. I always hated the fact that programs *had* to have MOD table entries to restore the SB value. With the DE mode I can treat SB like any other register (i.e., when saving and restoring) within the debugger. Hopefully I will be able to contribute some code to this project in the near future. For those still debugging their boards, my startup code is performing various diagnostic tests and display the results on the LEDs. This makes bringing up systems a little easier. As soon as I can figure out all kinds of useful diagnostics, I may design an EPROM specifically for bringing up PC532 motherboards. Oh well, back to the debugger. *** RAndy Hyde