ppc32: Fixes for non-zero PPC_MEMSTART on PPC440
PATCH 1/1 ppc32: Fixes for non-zero PPC_MEMSTART on PPC440
I have a custom embedded system with a 440GP derived CPU that places the memory starting at 0xc0000000 which requires a non-zero PPC_MEMSTART. There are a couple of places that assume PPC_MEMSTART is 0. This results in various tricky crashing during booting. Most of the problems are not accounting for PPC_MEMSTART during va/pa translations. My fixes convert these places to use pre-existing macros instead of duplicating the calculation.
The two items in head_4xx.S are critical, but I can't see a good way to link them in without an #ifdef, or maybe a CONFIG_* symbol. The alternate version of the tlb index picker will work for any platform, but is based on 'random' selection of the tlb index using the timebase rather than linear increment. I don't know if this is better, but it is an easy way to skip the problematic memory reference.
---
arch/ppc/kernel/head_4xx.S | 7 +++++++ arch/ppc/mm/4xx_mmu.c | 5 +++-- arch/ppc/mm/pgtable.c | 4 +++- include/asm-ppc/io.h | 4 ++-- include/asm-ppc/pgtable.h | 4 ++-- 5 files changed, 17 insertions(+), 7 deletions(-)
applies-to: cec49fea2095ec77123684854ed519f01cf890da 1ffdbeb034cf2ad10105c28b4c9b7588084d8d9d
arch/ppc/kernel/head_4xx.S +7 -0
@@ -771,10 +771,15 @@ tlb_4xx_index: finish_tlb_load: /* load the next available TLB index. */ +#ifdef NON_ZERO_PPC_MEMSTART + mftb r9 + andi. r9, r9, (PPC4XX_TLB_SIZE-1) +#else lwz r9, tlb_4xx_index@l(0) addi r9, r9, 1 andi. r9, r9, (PPC4XX_TLB_SIZE-1) stw r9, tlb_4xx_index@l(0) +#endif 6: /*
@@ -872,6 +877,7 @@ start_here: tlbia isync /* Flush shadow TLBs */ +#ifndef NON_ZERO_PPC_MEMSTART /* set up the PTE pointers for the Abatron bdiGDB. */ lis r6, swapper_pg_dir@h
@@ -881,6 +887,7 @@ start_here: stw r5, 0xf0(r0) /* Must match your Abatron config file */ tophys(r5,r5) stw r6, 0(r5) +#endif /* Now turn on the MMU for real! */ lis r4,MSR_KERNEL@h
arch/ppc/mm/4xx_mmu.c +3 -2
@@ -84,10 +84,11 @@ void __init MMU_init_hw(void)/* * Cache instruction and data space where the exception * vectors and the kernel live in real-mode. +* 512MB starting at the base physical address of the kernel. */ -mtspr (SPRN_DCCR ,0xF0000000 );/* 512 MB of data space at 0x0. */ -mtspr (SPRN_ICCR ,0xF0000000 );/* 512 MB of instr. space at 0x0. */ +mtspr (SPRN_DCCR ,0xF0000000 >> (PPC_MEMSTART /0x8000000 )); +mtspr (SPRN_ICCR ,0xF0000000 >> (PPC_MEMSTART /0x8000000 )); }#define LARGE_PAGE_SIZE_16M (1<<24)
arch/ppc/mm/pgtable.c +3 -1
@@ -190,7 +190,9 @@ __ioremap(phys_addr_t addr, unsigned lon* Don't allow anybody to remap normal RAM that we're using. * mem_init() sets high_memory so only do the check after that. */ -if ( mem_init_done && (p <virt_to_phys (high_memory)) ) +if ( mem_init_done && + p <virt_to_phys (high_memory) && + p >=PPC_MEMSTART ) {printk ("__ioremap(): phys addr " PHYS_FMT " is RAM lr %p\n" , p,__builtin_return_address (0 ));
include/asm-ppc/io.h +2 -2
@@ -422,7 +422,7 @@ extern inline void * bus_to_virt(unsigneextern inline unsigned long virt_to_phys (volatile void * address) {#ifndef CONFIG_APUS -return (unsigned long ) address -KERNELBASE ; +return __pa (address);#else return iopa ((unsigned long ) address);#endif
@@ -431,7 +431,7 @@ extern inline unsigned long virt_to_physextern inline void *phys_to_virt (unsigned long address) {#ifndef CONFIG_APUS -return (void *) (address +KERNELBASE ); +return __va (address);#else return (void *)mm_ptov (address);#endif
include/asm-ppc/pgtable.h +2 -2
@@ -724,12 +724,12 @@ extern pgprot_t phys_mem_access_prot(str#define pmd_page_kernel (pmd) \ ((unsigned long) __va(pmd_val(pmd) & PAGE_MASK))#define pmd_page (pmd) \ - (mem_map + (pmd_val(pmd) >> PAGE_SHIFT)) + pfn_to_page(pmd_val(pmd) >> PAGE_SHIFT)#else #define pmd_page_kernel (pmd) \ ((unsigned long) (pmd_val(pmd) & PAGE_MASK))#define pmd_page (pmd) \ - (mem_map + (__pa(pmd_val(pmd)) >> PAGE_SHIFT)) + (virt_to_page(pmd_val(pmd)))#endif /* to find an entry in a kernel page-table-directory */
---
0.99.9k
Quoted 8 lines · Jason Gunthorpe
I have a custom embedded system with a 440GP derived CPU that places the memory starting at
0xc0000000which requires a non-zeroPPC_MEMSTART. There are a couple of places that assumePPC_MEMSTARTis 0. This results in various tricky crashing during booting. Most of the problems are not accounting forPPC_MEMSTARTduring va/pa translations. My fixes convert these places to use pre-existing macros instead of duplicating the calculation.
Quoted 6 lines
The two items in
head_4xx.Sare critical, but I can't see a good way to link them in without an #ifdef, or maybe a CONFIG_* symbol. The alternate version of the tlb index picker will work for any platform, but is based on 'random' selection of the tlb index using the timebase rather than linear increment. I don't know if this is better, but it is an easy way to skip the problematic memory reference.
Shouldn't your board be using head_44x.S?
/me is confused...
josh
Quoted 7 lines · Jason Gunthorpe
I have a custom embedded system with a 440GP derived CPU that places the memory starting at
0xc0000000which requires a non-zeroPPC_MEMSTART. There are a couple of places that assumePPC_MEMSTARTis 0. This results in various tricky crashing during booting. Most of the problems are not accounting forPPC_MEMSTARTduring va/pa translations. My fixes convert these places to use pre-existing macros instead of duplicating the calculation.
Just out of curiosity: why did you do such a bogus setup in the first place ?
Ben.
Quoted 2 lines · Benjamin Herrenschmidt
Just out of curiosity: why did you do such a bogus setup in the first place ?
Historical.. This a FPGA design (Xilinx, embedded 405's) and the first time we deployed it was in conjunction with a 2nd MIPS processor that had system memory mapped 0 -> 0x200000. To keep the world sane and simple the 405's memory was desired to be non-overlapping with the MIPS world. The MIPS did care about the memory layout so it got to have RAM at address 0. This put the PPC ram at 0xC00000. The same basic components (mini embedded OS, internal FPGA cores, etc, etc) kept getting reused from project to project.
Nowadays, the 405 part of the original design has been retasked for something totally different and the MIPS is gone, taking along with it the reason for the odd memory map. But we built a stack of software which all assumes the classic memory map so the hardware just kept repeating it.
Fortunately for us Linux was pretty close to supporting the odd memory map, so we got to retain compatability with the old software, keep the hardware the same, and just patch the kernel a little bit.
Jason