Hi Simon, On Thu, Aug 24, 2023 at 10:11 AM Heinrich Schuchardt <[email protected]> wrote: > > > > Am 24. August 2023 01:57:55 MESZ schrieb Simon Glass <[email protected]>: > >Hi Heinrich, > > > >On Wed, 23 Aug 2023 at 14:19, Heinrich Schuchardt <[email protected]> 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 <[email protected]> >
To address Heinrich's concern, how about you turn off CONFIG_SPL_PCI in chromebook_samus and chromebook_samus_tpl? Regards, Bin

