Date: Fri, 28 Jan 2011 05:35:47 -0800 From: Devesh Rai <deveshkr@marvell.com> To: Mark Tinguely <marktinguely@gmail.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: RE: Changing virtual adress space layout Message-ID: <0DB595A2CB707F458400BE9663B6A7225E42E36569@SC-VEXCH2.marvell.com> In-Reply-To: <4D403FF3.7010500@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mark, Thank you very much for your detail response. Trick of not changing KERNVIR= TADDR worked. I was able to map 1GB of RAM into kva from KERNBASE(0x8000_0000) to OLD_KER= NBASE(0xC000_0000) using pmap_map_chunk api. I was able to write some data into mapped space and print it back.=20 But some doubt I still have 1) What is L1 and L2 page table in FreeBSD? Is there document which explain= s these vm concepts for arm? 2) How do I verify that this mapping indeed happened? Thanks & Regards Devesh -----Original Message----- From: Mark Tinguely [mailto:marktinguely@gmail.com]=20 Sent: Wednesday, January 26, 2011 9:08 PM To: Devesh Rai Cc: freebsd-arm@freebsd.org Subject: Re: Changing virtual adress space layout Reading your reply, it sounds like you want to directly map a full 1GB=20 to the KVA. The upper 1GB will always be partially used; for example it=20 has HIGH_VECTOR, and device mappings. So it sounds like you should set=20 KERNBASE to 0x8000_0000, map the RAM at 0x8000_0000 and leave the=20 KERNVIRTADDR where is was. The 1GB memory should be physically contiguous and properly aligned, so=20 you be able to directly add the addresses into the KVA "level 1=20 pagetable entries" either manually or with pmap_map_chunk(). Sorry, I do not have my development machine, so I can't do the=20 background work. Does changing the KERNBASE into a makeoption really=20 overriding the static define in /sys/arm/include/vm_machdep.h? A "cc -E"=20 (for example initarm() source file) would answer that question. The=20 other place to look would be in /sys/conf, but after a quick look, I did=20 not see any hardcoded values in the ARM specific files. Also, the KERNVIRTADDR does not equal KERNBASE on many ARM platforms ;=20 the boot loader may have put the kernel text at an offset to pass=20 parameters, and some older families use the ARM_USE_SMALL_ALLOC feature=20 - a form of direct ARM pagetable map. For example, the Sheeva port has=20 the KERNPHYSADDR/KERNVIRTADDR at 0x00900000/0xc0900000. --Mark. On 1/26/2011 8:34 AM, Devesh Rai wrote: > > Hi Mark, > > Actually I want to map large portion of RAM in kernel virtual address spa= ce. > To achieve this in Linux, I did following > > 1) boot kernel with 256M by setting CONFIG_CMDLINE=3D"mem=3D256M". This f= reed up more than 1GB of RAM for my module usages > 2) increase KVA to 3GB by setting CONFIG_VMSPLIT_1G=3Dy ( 1G for user and= 3GB for kernel) > 3) ioremap unused RAM ( 2GB - 256MB ) into Kernel virtual address space. > > Changing KERNBASE and KERNVIRTADDR "makeoption" from 0xc0000000 to 0x8000= 0000 did not worked for me. Kernel hang while loading. > > Thanks& Regards > Devesh > > -----Original Message----- > From: Mark Tinguely [mailto:marktinguely@gmail.com] > Sent: Thursday, January 13, 2011 10:00 PM > To: freebsd-arm@freebsd.org > Cc: Devesh Rai > Subject: Re: Changing virtual adress space layout > > On 1/13/2011 1:30 AM, Devesh Rai wrote: >> Hi, >> >> I am new to FreeBSD. Can some tell how to change virtual address space l= ayout in FreeBSD for arm? >> For x86, KVA_PAGES=3DN option is there in FreeBSD. In Linux, I used CON= FIG_VMSPLIT option. >> I am looking corresponding option for arm. >> >> Regards >> Devesh > I assume you have run out of space for the device virtual addresses. > > KERNBASE is hard coded in sys/arm/include/vm_param.h to be 0xc0000000. > > There is a related variable for each device configuration: the > KERNVIRTADDR "option" and "makeoption" values. This is usually in one > of the "std" file file for the device. KERNVIRTADDR sets the starting > location of the executable and is sometimes different than KERNBASE. > > The arm code does not map the from KERNBASE to 0xffff_ffff into the KVA. > Instead, there is a variable that determines the maximum size of the > kernel executable and kernel virtual address area. Above this defined > area lies the no-cache remap memory region, device map area, high > vector, etc. > > On a tangent note: There will be a great advantage in ARMv6/ARMv7 to go > to a 2GB UVA / 2GB KVA. > > --Mark. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0DB595A2CB707F458400BE9663B6A7225E42E36569>