> -----Original Message----- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: den 21 september 2012 14:50 > To: Robert Thorhuus > Cc: 'Tabi Timur-B04825'; u-boot@lists.denx.de > Subject: Re: [U-Boot] > arch/powerpc/lib/board.c:get_effective_memsize() for 4GB+ systems > > > On Sep 21, 2012, at 6:54 AM, Robert Thorhuus wrote: > > >> -----Original Message----- > >> From: Tabi Timur-B04825 [mailto:b04...@freescale.com] > >> Sent: den 21 september 2012 13:37 > >> To: Robert Thorhuus > >> Cc: Kumar Gala; u-boot@lists.denx.de > >> Subject: Re: [U-Boot] > >> arch/powerpc/lib/board.c:get_effective_memsize() for 4GB+ systems > >> > >> Robert Thorhuus wrote: > >> > >>> I really see the advantage of keeping this map you have. It is of > >>> course more compatible with different OSEs and you do not > >> need to do > >>> anything special with 32/64 bit cores. But at the same time > >> you never > >>> take advantage of a 64 bit core with this approach. > >> > >> U-Boot is a boot loader, not an operating system. What is U-Boot > >> supposed to do with more than 2GB of RAM? > >> > >>> How should I access my 24GB in U-Boot? > >> > >> You should not! > >> > >>> So really you are saying that I should have a 2GB map > window in my > >>> 32-bit address space and then move this window depending on what > >>> memory I want to access? A bit cumbersome I must say. But ok. > >> > >> Again, you're doing the wrong thing with U-Boot. It's a > boot loader. > >> It's supposed to find your OS, load it into memory, and > then boot it. > >> > >>> How about the U-Boot relocation? > >> > >>> As I see the code, it is not easy to decide where it should > >> relocate. > >>> It will be either relocated to end of RAM or if we have > >> more than 4G > >>> it will be at 4GB end. > >> > >> It relocates to the end of RAM or the end of 2GB, > whichever is lower. > >> It ignores all memory above 2GB. > >> > >>> What if you want to place U-Boot at 16MB for instance? Or > if you do > >>> not want a memory map hole at 4GB just because U-Boot > >> doesn't handle > >>> more than that? > >> > >> Again, you're missing the point about U-boot. > >> > >>> Last AND least I just want to say I'm used to creating > >> memory maps in > >>> bootloader which holds for the OS. It seems the time has come to > >>> annihilate my illusion... > >> > >> Yes, please kill it with fire! > >> > >> -- > >> Timur Tabi > >> Linux kernel developer at Freescale > >> > > > > Hello Timur! > > > > You really used the machine gun there ;) > > > > Ok. I'll just answer your 2GB+ usage question: > > > > Testing! > > No I will not be using much memory at all for > functionality. But the memory needs to be tested. What is > your proposal for that then? > > And I see U-Boot as the first software place for test and > debug. Maybe I want to read out RAM contents? > > > Robert, > > We have seen some cases for u-boot to access >4G of memory > directly. However, the effort to get u-boot to be a 64-bit > clean just has never warranted the investment for the few > minor cases people have raised for wanting to address >4G directly. > > The one case I usually hear about is DDR test. We suggest > its easier to try and getting DDR testing to utilize a window > scheme into memory than it is for one to go make u-boot 64-bit. > > :) > > - k
Hello Kumar! Ok. Since this seems to be the verified way I'll walk it. I'll change the DDR testing to be "small" window based. Still I wonder why the choice was made to have U-Boot relocate in high memory rather than low memory and also not making it easy to configure the relocation. BR Robert _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
