From: Michal Simek <monstr@monstr.eu> To: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: linux-kernel@vger.kernel.org, Russell King <linux@arm.linux.org.uk>, Marc Zyngier <marc.zyngier@arm.com>, Grant Likely <grant.likely@secretlab.ca>, Will Deacon <will.deacon@arm.com>, Rob Herring <rob.herring@calxeda.com>, linux-arm-kernel@lists.infradead.org, Ohad Ben-Cohen <ohad@wizery.com>, Peter Crosthwaite <peter.crosthwaite@petalogix.com> Subject: Re: [RFC PATCH 7/8] ARM: vmlinux.lds: Setup physical load address not virtual Date: Mon, 18 Jun 2012 21:23:54 +0200 [thread overview] Message-ID: <4FDF804A.5080404@monstr.eu> (raw) In-Reply-To: <alpine.LFD.2.02.1206181433130.23555@xanadu.home> On 06/18/2012 09:02 PM, Nicolas Pitre wrote: > On Mon, 18 Jun 2012, Michal Simek wrote: > >> 2012/6/18 Nicolas Pitre<nicolas.pitre@linaro.org> >> >>> On Mon, 18 Jun 2012, Michal Simek wrote: >>> >>>> Setup correct virtual and physical address in ELF LOAD section. >>> >>> We are moving to a single kernel binary for multiple targets, including >>> targets with different physical load addresses. The kernel code figures >>> out at run time what the actual physical address is when >>> CONFIG_ARM_PATCH_PHYS_VIRT is set which is the default these days. In >>> other words, we don't know the physical offset at build time in that >>> case and CONFIG_PHYS_OFFSET is simply not defined. >>> >> >> ok. good to know and nice features. In that case I expect that you are >> using any binary format and you copy it to memory and run it. Code >> find out where it runs and based on that setup things. > > Exact. ok. One more question about this feature. What is the alignment for it? I mean I have done the similar feature for Xilinx ppc440 and alignment depends on MMU TLB size. > >> (BTW: This is very interesting for me to implement it on Microblaze. Can >> you point me to that kernel code part? or any doc?) > > You could have a look at https://wiki.ubuntu.com/Specs/ARMSingleKernel, > especially the section "Optimized virt_to_phys() with a runtime > determined PHYS_OFFSET". > > Then the following commits should be of interest: > > 72a20e22f4 "ARM: P2V: eliminate head.S use of PHYS_OFFSET for !XIP_KERNEL" > > dc21af99fa "ARM: P2V: introduce phys_to_virt/virt_to_phys runtime patching" ok. Thanks will look at it. > >> But can you do it with elf? > > No. ok > >> Please correct me if I am wrong IRC ARM Qemu uses zImage but it is no >> problem to use elf file. For this case >> Qemu elf loader also uses physical addresses from ELF and also entry point. > > If you want to use the ELF image, then you need to hardcode the physical > memory location in its header, and that's something we want to get away > from because it prevents a single kernel binary image from being used on > different targets with different memory layouts. Same issue with > u-Boot's legacy uImage format. And are you able to get these information away from ELF? Or you just need to set it up to any default value. I would expect to 0x0. > >> I haven't played with CONFIG_ARM_PATCH_PHYS_VIRT option but what is elf >> entry point for this case? > > For the kernel image itself it is the kernel virtual address. Is it used somewhere? Or is it just setup to virtual address and no code use it? I mean that kernel virtual entry point. I expect that if CONFIG_ARM_PATCH_PHYS_VIRT=y then CONFIG_PHYS_OFFSET is not setup Then LOAD_OFFSET should be equal to CONFIG_PAGE_OFFSET. > > For the relocatable zImage decompressor wrapper it is 0. ok. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
WARNING: multiple messages have this Message-ID (diff)
From: monstr@monstr.eu (Michal Simek) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH 7/8] ARM: vmlinux.lds: Setup physical load address not virtual Date: Mon, 18 Jun 2012 21:23:54 +0200 [thread overview] Message-ID: <4FDF804A.5080404@monstr.eu> (raw) In-Reply-To: <alpine.LFD.2.02.1206181433130.23555@xanadu.home> On 06/18/2012 09:02 PM, Nicolas Pitre wrote: > On Mon, 18 Jun 2012, Michal Simek wrote: > >> 2012/6/18 Nicolas Pitre<nicolas.pitre@linaro.org> >> >>> On Mon, 18 Jun 2012, Michal Simek wrote: >>> >>>> Setup correct virtual and physical address in ELF LOAD section. >>> >>> We are moving to a single kernel binary for multiple targets, including >>> targets with different physical load addresses. The kernel code figures >>> out at run time what the actual physical address is when >>> CONFIG_ARM_PATCH_PHYS_VIRT is set which is the default these days. In >>> other words, we don't know the physical offset at build time in that >>> case and CONFIG_PHYS_OFFSET is simply not defined. >>> >> >> ok. good to know and nice features. In that case I expect that you are >> using any binary format and you copy it to memory and run it. Code >> find out where it runs and based on that setup things. > > Exact. ok. One more question about this feature. What is the alignment for it? I mean I have done the similar feature for Xilinx ppc440 and alignment depends on MMU TLB size. > >> (BTW: This is very interesting for me to implement it on Microblaze. Can >> you point me to that kernel code part? or any doc?) > > You could have a look at https://wiki.ubuntu.com/Specs/ARMSingleKernel, > especially the section "Optimized virt_to_phys() with a runtime > determined PHYS_OFFSET". > > Then the following commits should be of interest: > > 72a20e22f4 "ARM: P2V: eliminate head.S use of PHYS_OFFSET for !XIP_KERNEL" > > dc21af99fa "ARM: P2V: introduce phys_to_virt/virt_to_phys runtime patching" ok. Thanks will look at it. > >> But can you do it with elf? > > No. ok > >> Please correct me if I am wrong IRC ARM Qemu uses zImage but it is no >> problem to use elf file. For this case >> Qemu elf loader also uses physical addresses from ELF and also entry point. > > If you want to use the ELF image, then you need to hardcode the physical > memory location in its header, and that's something we want to get away > from because it prevents a single kernel binary image from being used on > different targets with different memory layouts. Same issue with > u-Boot's legacy uImage format. And are you able to get these information away from ELF? Or you just need to set it up to any default value. I would expect to 0x0. > >> I haven't played with CONFIG_ARM_PATCH_PHYS_VIRT option but what is elf >> entry point for this case? > > For the kernel image itself it is the kernel virtual address. Is it used somewhere? Or is it just setup to virtual address and no code use it? I mean that kernel virtual entry point. I expect that if CONFIG_ARM_PATCH_PHYS_VIRT=y then CONFIG_PHYS_OFFSET is not setup Then LOAD_OFFSET should be equal to CONFIG_PAGE_OFFSET. > > For the relocatable zImage decompressor wrapper it is 0. ok. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
next prev parent reply other threads:[~2012-06-18 19:24 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-06-18 11:30 ARM SMP/GIC/LDS patches for Xilinx Zynq remoteproc Michal Simek 2012-06-18 11:30 ` Michal Simek 2012-06-18 11:30 ` [RFC PATCH 1/8] ARM: gic: Support forcing cpumask for possible cpus in the system Michal Simek 2012-06-18 11:30 ` Michal Simek 2012-06-18 11:33 ` Russell King - ARM Linux 2012-06-18 11:33 ` Russell King - ARM Linux 2012-06-18 11:41 ` Michal Simek 2012-06-18 11:41 ` Michal Simek 2012-06-20 6:48 ` Michal Simek 2012-06-18 11:30 ` [RFC PATCH 2/8] ARM: gic: Export gic_raise_softirq function for kernel modules Michal Simek 2012-06-18 11:30 ` Michal Simek 2012-06-18 11:30 ` [RFC PATCH 3/8] ARM: gic: Introduce new gic_set_cpu Michal Simek 2012-06-18 11:30 ` Michal Simek 2012-06-18 11:30 ` [RFC PATCH 4/8] ARM: smp: Move cpu initialization directly to ipi_cpu_stop Michal Simek 2012-06-18 11:30 ` Michal Simek 2012-06-18 11:34 ` Russell King - ARM Linux 2012-06-18 11:34 ` Russell King - ARM Linux 2012-06-18 11:53 ` Michal Simek 2012-06-18 11:53 ` Michal Simek 2012-06-18 11:30 ` [RFC PATCH 5/8] AMP: smp: Extend number of IPIs Michal Simek 2012-06-18 11:30 ` Michal Simek 2012-06-18 11:35 ` Russell King - ARM Linux 2012-06-18 11:35 ` Russell King - ARM Linux 2012-06-18 11:54 ` Michal Simek 2012-06-18 11:54 ` Michal Simek 2012-06-18 11:30 ` [RFC PATCH 6/8] ARM: smp: Use generic API for ipi Michal Simek 2012-06-18 11:30 ` Michal Simek 2012-06-18 11:36 ` Russell King - ARM Linux 2012-06-18 11:36 ` Russell King - ARM Linux 2012-06-18 11:54 ` Michal Simek 2012-06-18 11:54 ` Michal Simek 2012-06-18 11:30 ` [RFC PATCH 7/8] ARM: vmlinux.lds: Setup physical load address not virtual Michal Simek 2012-06-18 11:30 ` Michal Simek 2012-06-18 14:06 ` Nicolas Pitre 2012-06-18 14:06 ` Nicolas Pitre 2012-06-18 18:15 ` Michal Simek 2012-06-18 19:02 ` Nicolas Pitre 2012-06-18 19:02 ` Nicolas Pitre 2012-06-18 19:23 ` Michal Simek [this message] 2012-06-18 19:23 ` Michal Simek 2012-06-18 21:10 ` Nicolas Pitre 2012-06-18 21:10 ` Nicolas Pitre 2012-06-19 4:16 ` Michal Simek 2012-06-18 11:30 ` [RFC PATCH 8/8] ARM: vmlinux.lds: Setup correct entry point to physical address Michal Simek 2012-06-18 11:30 ` Michal Simek 2012-06-18 11:37 ` Russell King - ARM Linux 2012-06-18 11:37 ` Russell King - ARM Linux 2012-06-18 11:45 ` Michal Simek 2012-06-18 11:45 ` Michal Simek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4FDF804A.5080404@monstr.eu \ --to=monstr@monstr.eu \ --cc=grant.likely@secretlab.ca \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=marc.zyngier@arm.com \ --cc=nicolas.pitre@linaro.org \ --cc=ohad@wizery.com \ --cc=peter.crosthwaite@petalogix.com \ --cc=rob.herring@calxeda.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.