* XIP probelm
@ 2005-10-21 16:22 Sreeni
2005-10-21 19:45 ` linux-os (Dick Johnson)
0 siblings, 1 reply; 2+ messages in thread
From: Sreeni @ 2005-10-21 16:22 UTC (permalink / raw)
To: linux-os, linux-kernel
Hi,
I have a montavista XIP kernel running on ARM and my kernel will be in
the flash. Since its XIP, I know that the ".text" portion of the
kernel will be executed from flash but that ".data" needs to be placed
in SDRAM. Now my question is - based on what offset this data will be
placed?
My SDRAM physicall address starts at 3000_0000 and flash starts at
0100_0000. when i allocated a global variable in the kernel module and
when i try to check its actually physical address using virt_to_phys,
its giving me the address in the range of 0100_0000 ~ 0600_0000 which
is my flash (the PAGE_OFFSET doesn't work in case of XIP).
Can you please help in knowing the physical address of my .data
portion in this situation.
Thanks
Shree
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: XIP probelm
2005-10-21 16:22 XIP probelm Sreeni
@ 2005-10-21 19:45 ` linux-os (Dick Johnson)
0 siblings, 0 replies; 2+ messages in thread
From: linux-os (Dick Johnson) @ 2005-10-21 19:45 UTC (permalink / raw)
To: Sreeni; +Cc: linux-kernel
On Fri, 21 Oct 2005, Sreeni wrote:
> Hi,
>
> I have a montavista XIP kernel running on ARM and my kernel will be in
> the flash. Since its XIP, I know that the ".text" portion of the
> kernel will be executed from flash but that ".data" needs to be placed
> in SDRAM. Now my question is - based on what offset this data will be
> placed?
>
> My SDRAM physicall address starts at 3000_0000 and flash starts at
> 0100_0000. when i allocated a global variable in the kernel module and
> when i try to check its actually physical address using virt_to_phys,
> its giving me the address in the range of 0100_0000 ~ 0600_0000 which
> is my flash (the PAGE_OFFSET doesn't work in case of XIP).
>
> Can you please help in knowing the physical address of my .data
> portion in this situation.
>
> Thanks
> Shree
>
I don't know about the ARM in particular, but if you look
in ../arch/arm/boot/compressed/vmlinux.lds.in, you will see
that this linker-file simply allocates the start addresses
of each section as the next available address. The same
is true of ../arch/arm/boot/bootp.lds. If you expect to
have code the data elements and stack accessed at a
specific physical offset, you modify the linker files().
Note that "." means "right here", just like '$' in many
assemblers. You can specify a physical offset simply
as:
ENTRY(_start)
SECTIONS
{
. = 0x01000000 <== like this for code
.text : {
...
... }
.rodata : { }
. = 0x30000000 <== like this data
.data : { }
.bss : { }
}
In the above, we have put .rodata (initialized ASCII stuff)
right after the code in the .text section. You may need to
extract this from the binary blob to put into your NVRAM.
Also, any initialzed data needs to be relocated to your
writable SDRAM and the .bss stuff needs to be zeroed.
This is non-trivial. You may want to create a ".reloc"
section which contains your initialized data, put it
in your flash, and relocate it at startup.
Basically executing-in-place is BAD. Flash should exist
in some little window where the code gets sucked out,
loaded at the correct offset in RAM, then you jump
there and close the little window. RAM, even SDRAM,
is cheaper than NAND FLASH. You can boot instantly
even as I have shown.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-10-21 19:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-10-21 16:22 XIP probelm Sreeni
2005-10-21 19:45 ` linux-os (Dick Johnson)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®