Hi Christian,
On Wed, May 23, 2018 at 9:39 PM, Christian Gmeiner christian.gmeiner@gmail.com wrote:
Hi Bin,
Am Mi., 23. Mai 2018 um 15:10 Uhr schrieb Bin Meng bmeng.cn@gmail.com:
Hi Christian,
On Wed, May 23, 2018 at 8:00 PM, Christian Gmeiner christian.gmeiner@gmail.com wrote:
If we use u-boot as coreboot payload with a generic dts without any ranges specified we fail in pci pre_probe and our pci bus is not usable.
What do you mean by "a generic dts"?
The coreboot payload needs to specify a dedicated dts for that board, for example to build a coreboot payload for minnowmax, we need specify minnowmax.dts in the Kconfig. README.x86 documents this.
Yeah.. so in my eyes a "generic dts" contains only this part regarding pci:
pci { compatible = "pci-x86"; #address-cells = <0x3>; #size-cells = <0x2>; };The important part is that it does not contain any ranges. Coreboot is the one who does the pci bus setup (assigning memory windows for devices etc). So I do not want to know in u-boot at build time (ranges thing for pci) how the pci bus looks regarding addresses. My end goal is one generic u-boot payload that gets used for different FSP 2.0 based boards.
I see your point. Then they way we support coreboot might be changed. We may create a generic U-Boot payload for coreboot targets. Can you respin the patch to address these comments, like u-boot -> U-Boot, adding detailed info to the commit message about this, and update README.x86?
Regards, Bin