On Sep 07, 2010, at 17:40, Peter Tyser wrote:
Hi Kyle,
The latest u-boot.git still seems to have the P2020DS lines that I referenced in "Makefile", and it has no references at all to "P2020DS" in the "boards.cfg" file.
It looks like the top-level Makefile is still required for boards that support multiple configs, eg 'make P2020DS_36BIT' will configure U-Boot to compile a 36-bit addressable U-Boot image while 'make P2020DS' will configure a 32-bit addressable U-Boot image, but they both use the same Makefile rule with some fancy parsing. So I guess if you have a need for both a 32 and 36bit version of U-Boot you'll to modify the Makefile like your original patch did unfortunately. If you don't need to support both U-Boot configs, you can go the route of other similar boards that are only in boards.cfg, eg P4080DS, P1022DS, XPedite5370, etc.
Hmm... Well I'd like to just have my config always be 36-bit to support up to 4GB of RAM. On the other hand, I also still need to support 32-bit kernels (with only 2GB of usable RAM, obviously). Unfortunately right now I don't see any way of doing both from the same U-Boot image and device tree, as a 36-bit U-Boot maps critical I/O much higher in physical address space.
This leads to another question: Is there any way to create a memory hole just like x86_64 systems do? Specifically, I'm thinking about a physical memory-map like this:
0x00000000 - 0x7fffffff [ 2GB] DDR2 Memory 0x80000000 - 0x9fffffff [512MB] PCIE3 Window 0xa0000000 - 0xbfffffff [512MB] PCIE2 Window 0xc0000000 - 0xdfffffff [512MB] PCIE1 Window 0xe0000000 - 0xefffffff [256MB] FLASH (2x128MB) 0xf0000000 - 0xffffffff [256MB] Miscellaneous I/O resources 0x100000000 - 0x17fffffff [ 2GB] DDR2 Memory, inaccessible to 32-bit OS
This is basically the same as my current 32-bit memory mapping, but with all memory above 2GB mapped separately further up in the address space.
From what I understand there would be 2 parts to the change:
(1) Modifying U-Boot to have "memory hole" start and end addresses, between which it would not create TLB entries that map to RAM. (2) Modifying U-Boot and/or the kernel to split the RAM into 2 ranges in the device tree.
I'm very willing to try to tackle this, but I'd need some pointers from the U-Boot community about where to start.
Cheers, Kyle Moffett