Re: [PATCH 1/2] powerpc: add kexec support on FSL-Book-E
wilbur.chan wrote: Hi Sebastian, Hi Wilbur, Recently I've implemented non-SMP kexec on MPC8572 and P2020ds(2G ram). I modified your misc_32.S that , I setuped two '1G' entries after the rfi instruction, so that I did not need to setup mapping for instruction address. If you send some patches I could add them to my tree so we have everything together. As for SMP supporting,I tried to close one of the CPUs in default_machine_kexec, and found that , when cpu1 closed ,and if the second kernel is NON- SMP,everything went well.so I added some code in kexec-tools, to make sure the 'kexec' process was running on CPU 0. I remember that ppc64 had some code to suspend and start the second CPU in the purgatory code. Not sure if there is a generic way for this on ppc32 or it is a book-e thing. Haven't look at it (yet). So, there left one problem, I can not start the second SMP-kernel, even if I closed CPU1. Any suggestions? The interesting thing is where do you hang/crash. It could be possible that the kernel is waiting for the non-boot cpus to show up and it doesn't. Have you look how u-boot prepares the cpus and how kernel disables them on shutdown? PTW: no-smp --- no-smp.OK no-smp ---smp...OK Does this mean your smp kernel has more that one CPU or just one? smp(with cpu1 closed)no-smp..OK smpw(with cpu1 closed)smp FAILED regards, wilbur Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re:[PATCH 1/2] powerpc: add kexec support on FSL-Book-E
2009/8/5, Sebastian Andrzej Siewior bige...@linutronix.de: There is no SMP support. The other CPUs are not halted/resumed. At the time of writing it I did not have a SMP machine so I did not implement it. Sebastian Hi Sebastian, Recently I've implemented non-SMP kexec on MPC8572 and P2020ds(2G ram). I modified your misc_32.S that , I setuped two '1G' entries after the rfi instruction, so that I did not need to setup mapping for instruction address. As for SMP supporting,I tried to close one of the CPUs in default_machine_kexec, and found that , when cpu1 closed ,and if the second kernel is NON- SMP,everything went well.so I added some code in kexec-tools, to make sure the 'kexec' process was running on CPU 0. So, there left one problem, I can not start the second SMP-kernel, even if I closed CPU1. Any suggestions? PTW: no-smp --- no-smp.OK no-smp ---smp...OK smp(with cpu1 closed)no-smp..OK smpw(with cpu1 closed)smp FAILED regards, wilbur ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Re:[PATCH 1/2] powerpc: add kexec support on FSL-Book-E
* wilbur.chan | 2009-08-02 09:25:43 [+0800]: Hi, Sebastian, Hi Wilbur, In your patch of Booke support for kexec , it setup a 1GB TMP mapping and jump to it. But I saw that, the max size for an e500 entry is 256M??so I changed your code to setup 4*256M entries, and it works well on mpc8541. The e500 core family reference manual [0] in chapter 12.2.2 (Variable-Sized Pages) says e500v1 supports only up to 256MiB and e500v2 supports up to 4GiB. So this code is e500v2 but not on purpose. Howerver,it didn't work on mpc8548(e500 v2) and P2020ds(SMP,e500 v2) , and 'rfi' to final_copy_code failed.(I also setup a 1:1 mapping for serial ,so I can trap the flowchart in relocate_new_kernel) Any suggestions about this ? Thank you very much. There is no SMP support. The other CPUs are not halted/resumed. At the time of writing it I did not have a SMP machine so I did not implement it. In general it should work on e500v2 boxes. There is one ugly thing: I did not setup the stack in the purgatory code. That means the purgatory code (and everything after it) is using kernel's old stack. This might corrupt things. I don't let purgatory code jump to the kernel code. Instead I jump to a tiny wrapper that is linked at 8Mib and takes the device tree which was handed over, uncompresses the kernel to 0x0 and jumps there. Since there is a gap betwwen 0 and 8MiB I usually have my purgatory stack there. Therefore the wrapper around kernel has to bring its own stack. regards, wilbur [0] E500CORERM.pdf Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re:[PATCH 1/2] powerpc: add kexec support on FSL-Book-E
Hi, Sebastian, From: Sebastian Andrzej Siewior bigeasy at linutronix.de The relocate_new_kernel() code usually disables the MMU and the small code operates on physicall pages while moving the kernel to its final position. Book-E doesn't support this so a 1:1 mapping must be created. This patch adds support for FSL-BOOK-E implementation. Signed-off-by: Sebastian Andrzej Siewior bigeasy at linutronix.de + xorir6,r4,1 /* Setup TMP mapping in the other Address space */ + slwir6,r6,12 + orisr6,r6,(MAS1_VALID|MAS1_IPROT)@h + ori r6,r6,(MAS1_TSIZE(BOOKE_PAGESZ_1GB))@l + mtspr SPRN_MAS1,r6 . + /* find our address */ + addir7, r30, final_copy_code - relocate_new_kernel + + mtspr SPRN_SRR0,r7 + mtspr SPRN_SRR1,r6 + rfi In your patch of Booke support for kexec , it setup a 1GB TMP mapping and jump to it. But I saw that, the max size for an e500 entry is 256M，so I changed your code to setup 4*256M entries, and it works well on mpc8541. Howerver,it didn't work on mpc8548(e500 v2) and P2020ds(SMP,e500 v2) , and 'rfi' to final_copy_code failed.(I also setup a 1:1 mapping for serial ,so I can trap the flowchart in relocate_new_kernel) Any suggestions about this ? Thank you very much. regards, wilbur ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
