I'm trying to understand where the value of virt_address inside kernel.ld.arm is coming from. The value is currently 0xf0000000 and the kernel's interrupt vector table is placed at 0xffff0000.
On my Cortex-A9 + uATX Versatile Express board this corresponds to the HSB AXI (peripherals communication bus). The memory map for the RealView Emulation Baseboard maps the 0xf0000000 area to logic tile site 2.
An objdump of the fiasco image shows that a number of kernel sections are being placed into 0xf0000000 and higher. And things work, but I would think that the correct address should be somewhere in RAM. (RAM which you then have to not withhold from sigma0.)
When I try to move the virt_address and .ivt address to somewhere in DRAM like 0x90000000 and 0x9fffffff respectively the kernel fails to load. Maybe because access is restricted although I don't think the MMU would have been turned on yet (but I haven't yet found the place where the MMU is turned on--I would guess by sigma0 or fiasco).
Thanks,
On Tue Nov 08, 2011 at 18:03:38 -0800, Wesley Miaw wrote:
I'm trying to understand where the value of virt_address inside kernel.ld.arm is coming from. The value is currently 0xf0000000 and the kernel's interrupt vector table is placed at 0xffff0000.
Which is a processor requirement.
On my Cortex-A9 + uATX Versatile Express board this corresponds to the HSB AXI (peripherals communication bus). The memory map for the RealView Emulation Baseboard maps the 0xf0000000 area to logic tile site 2.
Those are physical addresses, vectors are virtual.
An objdump of the fiasco image shows that a number of kernel sections are being placed into 0xf0000000 and higher. And things work, but I would think that the correct address should be somewhere in RAM. (RAM which you then have to not withhold from sigma0.)
The kernel also runs in virtual addresses, so 0xf0000000 is backed with memory.
When I try to move the virt_address and .ivt address to somewhere in DRAM like 0x90000000 and 0x9fffffff respectively the kernel fails to load. Maybe because access is restricted although I don't think the MMU would have been turned on yet (but I haven't yet found the place where the MMU is turned on--I would guess by sigma0 or fiasco).
You cannot move the vector table somewhere else, and also again virt != phys.
Adam
On Thu, November 10, 2011 02:48, Adam Lackorzynski wrote:
On Tue Nov 08, 2011 at 18:03:38 -0800, Wesley Miaw wrote:
An objdump of the fiasco image shows that a number of kernel sections are being placed into 0xf0000000 and higher. And things work, but I would think that the correct address should be somewhere in RAM. (RAM which you then have to not withhold from sigma0.)
The kernel also runs in virtual addresses, so 0xf0000000 is backed with memory.
Thank you for the reply. I guess I was confused because I am using the RealView Debugger to view my memory and I thought it was showing me physical memory. Plus, all the other addresses appear to be mapping based on the Cortex-A9 physical memory map.
l4-hackers@os.inf.tu-dresden.de