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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
