Hi Tom, I still don't know how to increase dram size available to Linux under aarch64 fvp but I think I have another suggestion that may help to your specific problem. Please see inline.
On 6 February 2014 18:19, Tom Gall <tom.g...@linaro.org> wrote: > Thanks Victor! > > This doesn't bode well. > > I'm trying to debug a Chrome on armv8 build. Chrome loaded into gdb > with symbols is well over 1 Gig of memory. With everything else > running (as in my X env) things die pretty early due to lack of RAM to > allocate. I think you can use remote cross gdb based debugging in this situation. Just run gdbserver on target attached to Chrome and run aarch64-linux-gnu-gdb on host. Here is quick recap of steps if you did not do it before, ignore otherwise. On target start gdbserver like this: x) make sure that model network is configured and enabled, so you can reach it from host x) to start new process: gdbserver localhost:3333 <procname and args> x) to attach to already running process gdbserver localhost:3333 --attach <pid> On host: x) Make sure that you have copy of target rootfs that has debugging symbol information (all debuginfo) x) start aarch64-linux-gnu-gdb x) set sysroot in gdb point to target rootfs copy set sysroot /host/path/target_rootfs x) load executable symbols with file /host/path/to/executable x) connect to remote target target remote <ip_address_of_vfp>:3333 after that usual debugging ... Note 3333 is arbitrary tcp port number I picked, use any other if you wish. It will also have side effect that it will be quicker because all gdb related activity will be done on host and fvp just runs target executables only. I came from embedded world we do remote cross debugging all the time, sometimes in situation where debuginfo of single executable is bigger than 2G and target memory is only 512Mb .... Thanks, Victor > Given this is all in the sim, I just don't see adding swap storage as > a viable option. > > What would life be if we didn't have to face fun little things like this ? :-) > > > On Thu, Feb 6, 2014 at 5:57 PM, Victor Kamensky > <victor.kamen...@linaro.org> wrote: >> Interesting question. >> >> I think on model side it is controlled by 'bp.dram_size' >> parameter (set it with -C option): >> >> [kamensky@kamensky-w530 fastmodels]$ >> ./FVP_Base_AEMv8A-AEMv8A/models/Linux64_GCC-4.1/FVP_Base_AEMv8A-AEMv8A >> --list-params | grep dram_size >> bp.dram_size=0x4 # (int , >> init-time) default = '0x4' : Size of main memory in gigabytes (2, 4 >> or 8) : [0x2..0x8] >> >> However when I tried it, it did not have any >> effect, and even if list-params help claims that default >> is 4Gb, my Linux kernel sees only 2Gb. >> >> I think the next issue is some setting in uefi >> loader: uefi creates memory regions list that is >> passed to the kernel. I see in uefi: >> >> ./ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc >> >> # System Memory (2GB) >> gArmTokenSpaceGuid.PcdSystemMemoryBase|0x80000000 >> gArmTokenSpaceGuid.PcdSystemMemorySize|0x80000000 >> >> and I cannot set it much bigger because PcdSystemMemorySize >> is defined as UINT32 in ./ArmPkg/ArmPkg.dec like this: >> >> # System Memory (DRAM): These PCDs define the region of in-built system >> memory >> # Some platforms can get DRAM extensions, these additional regions >> will be declared >> # to UEFI by ArmPLatformPlib >> gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT32|0x00000029 >> gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT32|0x0000002A >> >> At this point I don't see where/how to change ArmPLatformPlib get >> more memory available to Linux. >> >> Thanks, >> Victor >> >> On 6 February 2014 13:35, Tom Gall <tom.g...@linaro.org> wrote: >>> Is there a way to set how much memory an armv8 box will get when >>> running in the model? >>> >>> I'll really like to avoid setting up swap :-) >>> >>> Thanks! >>> >>> -- >>> Regards, >>> Tom >>> >>> "Where's the kaboom!? There was supposed to be an earth-shattering >>> kaboom!" Marvin Martian >>> Tech Lead, Graphics Working Group | Linaro.org │ Open source software >>> for ARM SoCs >>> w) tom.gall att linaro.org >>> h) tom_gall att mac.com >>> >>> _______________________________________________ >>> linaro-dev mailing list >>> linaro-dev@lists.linaro.org >>> http://lists.linaro.org/mailman/listinfo/linaro-dev > > > > -- > Regards, > Tom > > "Where's the kaboom!? There was supposed to be an earth-shattering > kaboom!" Marvin Martian > Tech Lead, Graphics Working Group | Linaro.org │ Open source software > for ARM SoCs > w) tom.gall att linaro.org > h) tom_gall att mac.com _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
