Assignment 4, Solutions

A problem: Write out the entire makefile for the project, assuming that the makefile and all of the other files for this project are stored in the same directory, probably a directory named mush. of the code goes in the same directory. (1.0 point)

Note: This is not a machine problem. You are welcome to break mush up as suggested above to test your solution, but you are not required to do so, nor are you required to turn in your broken-up versions of mush.

# makefile for the mush shell
mush : main.o launch.o parseargv.o getcommand.o
        cc -o mush main.o launch.o parseargv.o getcommand.o

main.o : main.c getcommand.h parseargv.h launch.h
        cc main.c

getcommand.o : getcommand.c getcommand.h command.h
        cc getcommand.c

parseargv.o : parseargv.c parseargv.h command.h argv.h
        cc parseargv.c

launch.o : launch.c launch.h argv.h
        cc launch.c

a) Are the I/O device registers on this system mapped as memory addresses, or is there a separate address space for I/O, as on the classic x86 architecture? (0.3 points)

It uses memory mapped I/O.

b) What range of addresses are used for controlling the GPIO pins on this system. (0.3 points)

The addresses are given in Section 6.1, ranging from 0x7E200000 to 0x7E200080.

Note that this answer is complicated by the presence of a 2-layer MMU, as documented in Section 1.2. The addresses noted above are bus addresses. Using the information in Section 1.2.3, the physical addresses of the GPIO interface run from 0x20200000 to 0x2020080.

Furthermore, in the standard Linux Kernel, Section 1.2.2 says that the MMU is configured to mape these addresses to 0xF2200000 to 0xF220080. The mapping done by the MMU is a necessary thing, but the distinction between bus addresses and physical addresses seems to be gratuitous -- it is not the kind of thing that a system designer would do deliberately, but seems more likely to be a side effect of something that happened during the design process.

c) Assuming that the GPIO funciton select pins have been so that GPIO pins 0 to 7 are configured as outputs, what value sould you store in the GPSET0 and GPCLR0 registers in order to output the value C5₁₆. Note that bits are numbered in littleendian order. (0.4 points)

GPSET0 must contain a one in each position we want set, and GPCLR0 must contain a one in each position we we want to clear. Any position with a zero in both bits will be unchanged, while putting a one in both positions is ambiguous (meaning, both set and clear the bit).

So, to output C5 (hex) which is 11000101,
GPSET0 must contain ...0011000101 or 0x000000C5, and
GPCLR0 must contain ...0000111010 or 0x0000003A.

The example output driver given in the notes uses two device regtisters, COM1DATA and COM1LSR, and it only uses 8 bits from the data register and one bit from the line status register.

a) Which bits of which mini UART interface register correspond to the use made of COM1DATA in the notes? (0.5 points)

0x7E215040 AUX_MU_IO_REG Mini Uart I/O Data

Section 2.2.2 states that bits 7 to 0 hold the data, while the rest of the bits are ignored on output and set to zero on input.

b) Which bits of which mini UART interface register correspond to the use made of COM1LSR in the notes? (0.5 points)

0x7E215054 AUX_MU_LSR_REG Mini Uart Line Status
The bit assignments for the RxRD, RxOE, TxDE and TxID functions are identical to the assignments used in the notes.

The identical bit assignments are coincidence. Section 2.1.1 of the Broadcom manual says that the Mini UART is not 16650 compatible, but that the interface registers are deliberatly arranged like the corresponding 16550 interface registers. Looking up the 16650, Wikipedia implies that it was, in turn, compatible with the 8250 UART that was factory installed on the original IBM PC on which the material in the lecture notes was based.

Note: Given the above, you could now write code to output data to the mini UART on a Raspberry Pi, assuming that you had configured the GPIO pins appropriately so that the mini UART was connected, and assuming that you were running your code in such a way that it had access to the input-output device registers.