Random thoughts on Linux/MIPS Jun Sun ---------------------------------------------------------------------- Future directions: 2004/08/30: Since I am probably not going to work on Linux/MIPS much in the future, I think it is a nice to write down my personal wish list: . Have a common irq_init(), which does some common initialization and calls board_irq_init(). Rational: . promote code sharing . pave the way for further innovation . Streamline board start-up process. Get rid of prom_init(). See "Board start up meachnism". . Have mips_machine structure that lumps all machine specific routines and data together, e.g., board_irq_init, board_timer_setup, machine_group, machine_name, board_be_handler, etc... I feel pretty strongly about this one. If we do it right we will have almost zero common files which need to modified when a board is added or deleted. This will greatly enable linux/mips tree to be used and tracked by industry. It will also make it easier to maintain the community tree w.r.t. so many different CPUs and boards. . Use CPU counter as system timer. This will improve code sharing and pave the way for future innovation. See my posting http://www.linux-mips.org/archives/linux-mips/2004-04/msg00089.html http://www.linux-mips.org/archives/linux-mips/2004-04/msg00101.html http://www.linux-mips.org/archives/linux-mips/2004-04/msg00182.html I feel pretty strongly about this one too. . We need to have more structure CPU support. See "CPU startup sequence" below. However I don't really have a complete solution on this topic. . We need to improve the abstraction between MIPS common code and board specific code regarding SMP support. At least those "prom_xxx" naming sucks. Seriously there is more to the naming. I did not spend enough time to come up with a complete solution. Some of the ideas I have already discussed with Ralf, and most likely he disgreed. However he can be convinced. Keep on trying if you believe in the same ideas. ---------------------------------------------------------------------- cache 2001/12/06: . Introduce "way_offset" to mips_cpu.cache structure so that 1) we can combine cacheXXXLSB() with the same cacheXXX() routines 2) consolidate a couple of other CPU cache routines such as R5432. 2001/12/12: . the newly introducted flush_xxx_line_indexed() needs to take cache sets into consideration. Effert: 5. ---------------------------------------------------------------------- PCI 2001/12/02: . arch/mips/pci.c - we can use the same pci_bridge_check_io() routine in drivers/pci/setup-bus.c. . the following lines should be removed from include/asm-mips/pci.h #if (defined(CONFIG_DDB5074) || defined(CONFIG_DDB5476)) #undef PCIBIOS_MIN_IO #undef PCIBIOS_MIN_MEM #define PCIBIOS_MIN_IO 0x0100000 #define PCIBIOS_MIN_MEM 0x1000000 #endif 2001/12/17: . Assuming 1:1 mapping between PCI memory space and CPU physical space can be to restrictive. The restriction is felt when device with ISA mem (<2M, hardcoded decoding) is present (through PCI-ISA bridge). One of solution is to rewrite driver so that it uses isa_read/isa_write. *BUT* assuming we want to be more flexible with the 1:1 mapping, we can something like I said in the following quote" Jim Paris wrote: > > > > 1) Isn't the purpose of ioremap to remap I/O memory addresses to > > > physical ones? For an ISA architecture like mine, this means > > > it needs to add isa_slot_offset. > > > > Yes it is. Also see Documentation/IO-mapping.txt and the Alpha port. > > So I should modify ioremap to return (addr+isa_slot_offset) when > CONFIG_ISA is defined and the given I/O address is in the 16 MB ISA > range. I would consider it only as a workaround rather than a fix. You need to make sure all other PCI-based boards have isa_slot_offset set to 0. ioremap() has been used by many PCI device drivers, and on MIPS it assumes 1:1 mapping between PCI memory space and CPU physical space. It have been working so far either because PCI device BARs are shuffled around to match their physical address (from CPU point of view) or dev structure is modified propoerly with special fixups. Now when people using ioremap/readb/writeb method to access ISA memory space, which lives in the lower range of the "bus memory space", it will collide with system ram under 1:1 mapping assumption. Extending isa_slot_offset to something like 'mips_io_mem_offset' may be the right way to go. This implies 1) all PCI-based systems need to set this value to the physical address of the beginning of PCI memory space window. 2) ioremap() always add this base. 3) when assigning PCI BARs, we need to substract this offset from the corresponding physical address. Host-PCI controller needs to be setup accordingly to do the above substractive address translation. ---------------------------------------------------------------------- serial port 2001/11/27: . if PCI and SERIAL are configure, CONFIG_SERIAL_MANY_PORTS is defined and we have 64 serial ports, wasting 11K ram. Too wasteful. . Some board also intentionally defined SERIAL_MANY_PORTS. . Need a better solution to lower that number. ---------------------------------------------------------------------- Board start up meachnism 2001/11/09: . _detect and _setup pair . use a ELF section, reclaimable once kernel boots up From my email posted on 09/05, 2002: I talked about machine detection a while back. My idea is following: 0. all machines that are *configured* into the image will supply _detect() and _setup() functions. 1. at MIPS start up, we loop through all _detect(), which returns three values, a) run-time detection negative, b) run-time detection positive, and c) no run-time detection code, but I return positive because I am configured in. 2. the startup code resolves conflicts (which sometimes may panic); and decide on one machine. 3. then the startup code calls the right _setup() code which will set up the mach_type and other stuff. BTW, a side benenfit of doing this is that we can remove all the machine specific code in common files such as bootinfo.h, setup.c, etc, which are getting harder and harder to maintain as we are adding more and more embedded boards to the tree. If we push it to an extreme by using mechnism like do_initcalls(), we can achieve zero common source file modification when adding a new a machine. This will greatly facilitate embedded development as it allows more parallel development and allow people to maintain their own board code much easier before the code is submitted to the tree. ---------------------------------------------------------------------- CPU startup sequence 2001/11/16: . Need a clean, complete list of the functions/variables that all CPU must supply . Need a structured way to fill in all pointers and data. For example, we can use the following sequence . fill in default values . if CPU belongs to specific family (MIPS32), do some more settings . if CPU is a specific model, do some more fixups 2002/07/23: WIW, I believe CPU probing and setup should be done in a distributed, configurable fashion. . There is a global table, where each entry in the table have (at least) four fields: uint company_id uint processor_id uint revision_id void (*setup_cpu)(void); . cpu_probe() simply reads prid register and search through the table. If it finds matching one, then issue the (setup_cpu) call. . matching allows wildcard matching. Apparently more specific entry should be checked before more generic entries. . cpu cache routines and tlb routines are organized accordingly, so that static configurations can be done sensibly. ---------------------------------------------------------------------- Generic MIPS RTC: 2001/11/16: See the RFC in the mailing list ---------------------------------------------------------------------- Calibration of MIPS CPU counter 2001/11/09: Most cpus have counter. Most probably don't specify the frequency. It would be nice to calibrate it. so that 1) we get rid of various gettimeoffset_calibrate routines in arch/mips/kernel/time.c file 2) generally useful for other kernel time measurement. implementation: The variable probably should be put into cpu_mips structure. Calibrate should be done after interrupts is open. After "bogusMIPS calibration?" ---------------------------------------------------------------------- ---------------------------------------------------------------------- MIPS_ATOMIC_SET 2001/10/01: . The new sysmips/MIPS_AUTOMIC_SET patch in oss.sgi.com tree 1. Data swapping is not protected by irq blocking and unblocking. Potentially dangerious because 1) interrupt handler can mess with it and 2) preemptible kernel won't be happy with it. 2. calling do_page_fault() is not necessary for embedded systems without swap space. Probably improves performance a lot.