Hi Bin,
On Mon, 4 Sept 2023 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Aug 24, 2023 at 10:11 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 24. August 2023 01:57:55 MESZ schrieb Simon Glass sjg@chromium.org:
Hi Heinrich,
On Wed, 23 Aug 2023 at 14:19, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/23/23 20:47, Simon Glass wrote:
For x86 platforms, PCI is core to their operation and is managed in arch-specific code. Each platform has its own way of doing this. For TPL and some SPL implementations, the full driver model PCI is not used.
A recent change enabled full PCI in TPL/SPL for all boards. This breaks some x86 boards, so adjust it to skip that for x86.
Could you, please, give some more detail?
- Which boards are broken?
For example, chromebook_samus and chromebook_samus_tpl
- Don't these boards have a pci_init() function?
Yes, the same one you are calling.
- In what way does calling pci_init() lead to a failure?
It probes and sets up PCI devices and uses a lot of pre-alloc RAM.
It would be preferable to have all architectures and boards use the same high level API. Excluding x86 here looks more like a (necessary) hack than like a target state.
Fair enough, but on x86 we access PCI long before driver model is up. Generally we don't fully enumerate it in SPL as it is expensive. It is also pointless, since U-Boot proper does it again later.
Regards, Simon
Acked-by: Heinrich Schuchardt xypron.glpk@gmx.de
To address Heinrich's concern, how about you turn off CONFIG_SPL_PCI in chromebook_samus and chromebook_samus_tpl?
I dug into this a bit more...the root cause is that we are turning off CAR so the driver model tables are no-longer available. Accessing them causes a hang.
I will send a v2 which adds a flag to indicate this.
Regards, Simon