Re: [PATCH 00/12] Fixing TI Keystone2 kexec
On 05/11/16 at 10:32am, Russell King - ARM Linux wrote: > On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote: > > On 05/11/16 at 09:52am, Russell King - ARM Linux wrote: > > > I think you're confusing things. DT doesn't contain the boot alias > > > memory ranges - it's not a separate chunk of memory. It's an alias > > > of the same physical address space found higher in the physical > > > address range. > > > > Hmm, if we forget about kexec how does the 1st kernel get boot memory? > > not from DT? > > Just like any other ARM system, it pulls itself up by its shoe laces. > > The kernel assumes that it has been placed into RAM with at least 32KiB > of writable memory below it, which it uses for the initial page tables. > It "guesses" that the executing address, rounded down to I-forget-what- > boundary gives the base address of physical memory. > > It sets the page table up using that assumption. The kernel gets going > with C code, and only _then_ parses the DTB. > > If we then find that we're running on TI Keystone 2, part of the early > platform initialisation specifies to the ARM core code that the kernel > is to switch a high physical address space > 4GiB, and this provokes > a "dance" where we tear the MMU back down, run some more assembly code > to fix up the page tables, and re-initialise the MMU before returning > to the kernel C code, this time running in the high physical address > space. This break-modify-make is an architecture requirement. We > also record the physical address delta between the original physical > address space and the high physical address space so that we can reverse > the translation for code which needs identity mapping (eg, SMP bringup.) > > The DTB only contains the high physical address space memory information, > and the kernel now parses the DTB, and sets the page tables up properly > for the running system. Thanks for the explanation, so the DTB does not contain the delta info Please ignore the noise then. > > > > If we put it in DT, then we need a way to also describe that it is an > > > alias of some other bit of physical memory. > > > > I may missed the background, I just want kexec to get infomation just like > > the normal kernel. > > See above. What you're asking for isn't really possible. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] Fixing TI Keystone2 kexec
On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote: > On 05/11/16 at 09:52am, Russell King - ARM Linux wrote: > > I think you're confusing things. DT doesn't contain the boot alias > > memory ranges - it's not a separate chunk of memory. It's an alias > > of the same physical address space found higher in the physical > > address range. > > Hmm, if we forget about kexec how does the 1st kernel get boot memory? > not from DT? Just like any other ARM system, it pulls itself up by its shoe laces. The kernel assumes that it has been placed into RAM with at least 32KiB of writable memory below it, which it uses for the initial page tables. It "guesses" that the executing address, rounded down to I-forget-what- boundary gives the base address of physical memory. It sets the page table up using that assumption. The kernel gets going with C code, and only _then_ parses the DTB. If we then find that we're running on TI Keystone 2, part of the early platform initialisation specifies to the ARM core code that the kernel is to switch a high physical address space > 4GiB, and this provokes a "dance" where we tear the MMU back down, run some more assembly code to fix up the page tables, and re-initialise the MMU before returning to the kernel C code, this time running in the high physical address space. This break-modify-make is an architecture requirement. We also record the physical address delta between the original physical address space and the high physical address space so that we can reverse the translation for code which needs identity mapping (eg, SMP bringup.) The DTB only contains the high physical address space memory information, and the kernel now parses the DTB, and sets the page tables up properly for the running system. > > If we put it in DT, then we need a way to also describe that it is an > > alias of some other bit of physical memory. > > I may missed the background, I just want kexec to get infomation just like > the normal kernel. See above. What you're asking for isn't really possible. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] Fixing TI Keystone2 kexec
On 05/11/16 at 09:52am, Russell King - ARM Linux wrote: > On Wed, May 11, 2016 at 04:29:23PM +0800, Dave Young wrote: > > Hi, Russell > > > > On 04/28/16 at 10:26am, Russell King - ARM Linux wrote: > > > These changes are required for TI Keystone2 kexec to be functional. TI > > > Keystone2 has the run-time view of physical memory above 4GiB, but with > > > a boot time alias below 4GiB which can only be used during the early > > > boot. > > > > > > This means we need to translate run-time physical addresses (which the > > > kernel uses) to boot-time physical addresses, which, having discussed > > > with Eric, is what the kexec tools and kexec kernel API requires. > > > > > > We publish a special set of boot time resources in /proc/iomem, which > > > the (modified) kexec tools look for in preference to the normal resources. > > > Hence, if these are found, the kexec tools make use of these resources, > > > and thus kexec tools use the boot-time view of physical memory. > > > > I think getting memory ranges from device tree will be better than > > adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb > > you can refer to the patchset. > > I think you're confusing things. DT doesn't contain the boot alias > memory ranges - it's not a separate chunk of memory. It's an alias > of the same physical address space found higher in the physical > address range. Hmm, if we forget about kexec how does the 1st kernel get boot memory? not from DT? > > If we put it in DT, then we need a way to also describe that it is an > alias of some other bit of physical memory. I may missed the background, I just want kexec to get infomation just like the normal kernel. > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] Fixing TI Keystone2 kexec
On Wed, May 11, 2016 at 04:29:23PM +0800, Dave Young wrote: > Hi, Russell > > On 04/28/16 at 10:26am, Russell King - ARM Linux wrote: > > These changes are required for TI Keystone2 kexec to be functional. TI > > Keystone2 has the run-time view of physical memory above 4GiB, but with > > a boot time alias below 4GiB which can only be used during the early > > boot. > > > > This means we need to translate run-time physical addresses (which the > > kernel uses) to boot-time physical addresses, which, having discussed > > with Eric, is what the kexec tools and kexec kernel API requires. > > > > We publish a special set of boot time resources in /proc/iomem, which > > the (modified) kexec tools look for in preference to the normal resources. > > Hence, if these are found, the kexec tools make use of these resources, > > and thus kexec tools use the boot-time view of physical memory. > > I think getting memory ranges from device tree will be better than > adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb > you can refer to the patchset. I think you're confusing things. DT doesn't contain the boot alias memory ranges - it's not a separate chunk of memory. It's an alias of the same physical address space found higher in the physical address range. If we put it in DT, then we need a way to also describe that it is an alias of some other bit of physical memory. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] Fixing TI Keystone2 kexec
Hi, Russell On 04/28/16 at 10:26am, Russell King - ARM Linux wrote: > These changes are required for TI Keystone2 kexec to be functional. TI > Keystone2 has the run-time view of physical memory above 4GiB, but with > a boot time alias below 4GiB which can only be used during the early > boot. > > This means we need to translate run-time physical addresses (which the > kernel uses) to boot-time physical addresses, which, having discussed > with Eric, is what the kexec tools and kexec kernel API requires. > > We publish a special set of boot time resources in /proc/iomem, which > the (modified) kexec tools look for in preference to the normal resources. > Hence, if these are found, the kexec tools make use of these resources, > and thus kexec tools use the boot-time view of physical memory. I think getting memory ranges from device tree will be better than adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb you can refer to the patchset. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] Fixing TI Keystone2 kexec
Hi Russell, On Thu, Apr 28, 2016 at 10:26:44AM +0100, Russell King - ARM Linux wrote: > These changes are required for TI Keystone2 kexec to be functional. TI > Keystone2 has the run-time view of physical memory above 4GiB, but with > a boot time alias below 4GiB which can only be used during the early > boot. > > This means we need to translate run-time physical addresses (which the > kernel uses) to boot-time physical addresses, which, having discussed > with Eric, is what the kexec tools and kexec kernel API requires. > > We publish a special set of boot time resources in /proc/iomem, which > the (modified) kexec tools look for in preference to the normal resources. > Hence, if these are found, the kexec tools make use of these resources, > and thus kexec tools use the boot-time view of physical memory. > > The first three patches have been sitting in linux-next for a while. > I'm going to put the next ARM specific three into linux-next next week. > > I've sent Eric over a month ago all the patches, including the kexec > tools patches, but I've heard nothing back. I'm at a loss how to > make progress on these patches - and as I'm being hassled about this, > I'm going to be hassling the community about it, possibly with regular > re-posts until there is some progress. My experience is that usually Andrew Morton takes kexec patches and that this has been the situation for many years now. With regards to any kexec-tools patches that are appropriate for upstream: please send them to the kexec mailing list with me CCed and I will see about including them in the next release. If you have done so already then I apologise for having missed them. > Documentation/kdump/kdump.txt | 13 ++-- > arch/arm/boot/dts/keystone.dtsi | 8 + > arch/arm/include/asm/kexec.h | 24 +++ > arch/arm/include/asm/memory.h | 38 ++- > arch/arm/kernel/machine_kexec.c | 2 +- > arch/arm/kernel/setup.c | 65 > +-- > arch/arm/mach-keystone/keystone.c | 7 + > arch/arm/mm/idmap.c | 2 +- > arch/ia64/kernel/machine_kexec.c | 2 +- > include/linux/kexec.h | 42 +++-- > kernel/kexec.c| 3 +- > kernel/kexec_core.c | 30 +- > kernel/ksysfs.c | 4 +-- > 13 files changed, 193 insertions(+), 47 deletions(-) > > -- > RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/12] Fixing TI Keystone2 kexec
These changes are required for TI Keystone2 kexec to be functional. TI Keystone2 has the run-time view of physical memory above 4GiB, but with a boot time alias below 4GiB which can only be used during the early boot. This means we need to translate run-time physical addresses (which the kernel uses) to boot-time physical addresses, which, having discussed with Eric, is what the kexec tools and kexec kernel API requires. We publish a special set of boot time resources in /proc/iomem, which the (modified) kexec tools look for in preference to the normal resources. Hence, if these are found, the kexec tools make use of these resources, and thus kexec tools use the boot-time view of physical memory. The first three patches have been sitting in linux-next for a while. I'm going to put the next ARM specific three into linux-next next week. I've sent Eric over a month ago all the patches, including the kexec tools patches, but I've heard nothing back. I'm at a loss how to make progress on these patches - and as I'm being hassled about this, I'm going to be hassling the community about it, possibly with regular re-posts until there is some progress. Documentation/kdump/kdump.txt | 13 ++-- arch/arm/boot/dts/keystone.dtsi | 8 + arch/arm/include/asm/kexec.h | 24 +++ arch/arm/include/asm/memory.h | 38 ++- arch/arm/kernel/machine_kexec.c | 2 +- arch/arm/kernel/setup.c | 65 +-- arch/arm/mach-keystone/keystone.c | 7 + arch/arm/mm/idmap.c | 2 +- arch/ia64/kernel/machine_kexec.c | 2 +- include/linux/kexec.h | 42 +++-- kernel/kexec.c| 3 +- kernel/kexec_core.c | 30 +- kernel/ksysfs.c | 4 +-- 13 files changed, 193 insertions(+), 47 deletions(-) -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
