RE: User/kernel memory split

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Romit,
> -----Original Message-----
> From: linux-omap-owner@xxxxxxxxxxxxxxx 
> [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Dasgupta, Romit
> Sent: Monday, July 06, 2009 5:00 PM
> To: V, Hemanth; linux-arm-kernel@xxxxxxxxxxxxxxxxxxxxxx; 
> linux-omap@xxxxxxxxxxxxxxx
> Subject: RE: User/kernel memory split
> 
> 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!
These points were discussed in below thread.
http://lists.arm.linux.org.uk/lurker/message/20090626.181403.55450a9c.en.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux