With DT present I see the regions described in the .dtb file being properly excluded. So now the problem is that just under 3/4 of available RAM is visible, when we should be able to see all except the 48MB set aside just below the 1/2G boundary (which is used by other processor(s) on the SoC).
The comment in the .dts file is not quite right. The top 256MB *is* (or can be) accessible with HIGHMEM condfigured. However, when DT is present the dtb data (and the initrd) are copied to the very end of SDRAM by uboot, and a pointer to that device tree location is passed into the kernel startup code. Apparently the kernel cannot handle device tree (and maybe initrd data too) residing in HIGHMEM.
With DT present I see the regions described in the .dtb file being properly excluded. So now the problem is that just under 3/4 of available RAM is visible, when we should be able to see all except the 48MB set aside just below the 1/2G boundary (which is used by other processor(s) on the SoC).
The comment in the .dts file is not quite right. The top 256MB *is* (or can be) accessible with HIGHMEM condfigured. However, when DT is present the dtb data (and the initrd) are copied to the very end of SDRAM by uboot, and a pointer to that device tree location is passed into the kernel startup code. Apparently the kernel cannot handle device tree (and maybe initrd data too) residing in HIGHMEM.