Hemanth,
I might be missing something but please see below:
>
>
>Hemanth,
> Why do you want the split? Do you have physical mem > 1G
>in your system?
>
>We want to fit 512MB RAM on 2.6.27 Kernel which doesnot have highmem option.
>We also donot want to disturb the current I/O memory map
[Romit] As long as your physical memory is slightly less than 1GB, I do not
think highmem is necessary.
For I/O map: Kernel virtual addresses start from 0xC0000000. Adding 512M to it
gives 0xE0000000. So the virtual memory for IO space needs to be after this.
Currently the IO Map is
#define L4_WK_34XX_PHYS L4_WK_34XX_BASE /* 0x48300000 */
#define L4_WK_34XX_VIRT 0xd8300000
#define L4_WK_34XX_SIZE SZ_1M
#define L4_PER_34XX_VIRT 0xd9000000
#define L4_PER_34XX_SIZE SZ_1M
#define L4_EMU_34XX_VIRT 0xe4000000
#define L4_EMU_34XX_SIZE SZ_64M
#define OMAP34XX_GPMC_PHYS OMAP34XX_GPMC_BASE /* 0x6E000000 */
#define OMAP34XX_GPMC_VIRT 0xFE000000
#define OMAP34XX_GPMC_SIZE SZ_1M
#define OMAP343X_SMS_VIRT 0xFC000000
#define OMAP343X_SMS_SIZE SZ_1M
#define OMAP343X_SDRC_PHYS OMAP343X_SDRC_BASE /* 0x6D000000 */
#define OMAP343X_SDRC_VIRT 0xFD000000
#define OMAP343X_SDRC_SIZE SZ_1M
This is a problem as the existing virtual memory maps for I/O space would
overlap with 512M SDRAM. So, we need to redefine the virtual mapping after
0xe0000000. The IO_OFFSET is 0x90000000 currently.
For L4_WK_34XX_VIRT we need a minimum of 0xe0000000 - 0x48300000 i.e.
0x97D00000 as the new IO_OFFSET. But using this new IO_OFFSET for mapping
OMAP343x_GPMC_VIRT would result in an overflow(0x6E000000 + 0x97D00000 =
0x105D00000).
Using ioremap for these regions might help. But this needs changes to most
drivers. In that case these static mappings could go away and I think they
should. Some ARM kernel expert may comment!
-Romit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
