Benjamin Herrenschmidt wrote: > On Sat, 2009-11-28 at 21:43 +0100, Albert Herranz wrote: >> + * Prepare again the same BAT for MMU_init. >> + * This allows udbg I/O to continue working after the MMU is >> + * turned on for real. >> + * >> + * We are assuming here that exi_io_base is identity mapped. >> + */ >> + addr = ((unsigned long)exi_io_base) & 0xffff0000; >> + setbat(1, addr, addr, 128*1024, PAGE_KERNEL_NCG); > > How do you prevent that from overlapping otherwise valid kernel > mappings ? >
ug_udbg_init() is called from ppc_md.init_early. It doesn't overlap any valid kernel mappings because exi_io_base is hardcoded to an i/o region not used yet by the kernel. See udbg_early_grab_exi_io_base(). The setbat just prepares again, exactly in the same way, the same BAT that we got setup by setup_usbgecko_bat in head_32.S. _start __start > early_init > mmu_off # mmu off > clear_bats > flush_tlbs > initial_bats > setup_usbgecko_bat <--- BAT1 setup here > call_setup_cpu > init_idle_6xx ! relocate_kernel ! turn_on_mmu # mmu on ! start_here > machine_init >> udbg_early_init >>> udbg_init_usbgecko <--- BAT1 prepared again here for after MMU_init >> early_init_devtree > __save_cpu_setup > MMU_init # mmu off > load_up_mmu # mmu on ! start_kernel > You need to allocate the virtual space. For a debug thing like that, you > could use the fixmap. In fact, I think we should create a fixmap entry > or two always available for use by early debug. > Or give us back ppc_md.setup_io_mappings :) > Cheers, > Ben. > Thanks, Albert _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
