Scott Duplichan wrote: > set_var_mtrr_resource is passed a range of c0000-7fffffff. The > existing coreboot code assumes this range has already had the UMA > part removed, and adds it back: > > // Increase the base range and set up UMA as an UC hole instead > var_state.range_sizek += (uma_memory_size >> 10); > > What logic should deduct the reserved range from the DRAM range > before this code runs?
Good question. Or should the above code be removed? Why does UMA need special consideration? Is it any other reason than that it sometimes should be included in RAM size, and other times not? Scott Duplichan wrote: > The message "Adding UMA memory area, base=70000000 size=10000000" > refers to the physical address of the DRAM that becomes unavailable > due to UMA. This DRAM is never accessed using this physical > address. It is accessed through the frame buffer bar, which gets > assigned an address between top of memory and 4GB, such as > E8000000. Ignoring the real issue for a while, isn't this really stupid? Why not let the BAR point to actual DRAM instead, and free up some IO space? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
