[Macchiato] EDKII grub boot fails with PCIe init

[Ard Biesheuvel]

On 13 March 2018 at 16:23, Marcin Wojtas <mw at semihalf.com> wrote:
> Frederic,
>
>>>> Please use the size I suggested for the 'reg' property
>>>
>>>
>>> Sorry I missed that:
>>>
>>> [    1.463413] PCI: OF: host bridge /cp0/pcie at 0xe0000000 ranges:
>>> [    1.463427] PCI: OF:    IO 0xeff00000..0xeff0ffff -> 0x00000000
>>> [    1.463435] PCI: OF:   MEM 0xc0000000..0xdfffffff -> 0xc0000000
>>> [    1.463442] PCI: OF:   MEM 0x800000000..0x8ffffffff -> 0x800000000
>>> [    1.463481] pci-host-generic e0000000.pcie: ECAM at [mem
>>> 0xe0000000-0xefefffff] for [bus 00-fe]
>>> [    1.463525] pci-host-generic e0000000.pcie: PCI host bridge to bus
>>> 0000:00
>>> [    1.463531] pci_bus 0000:00: root bus resource [bus 00-fe]
>>> [    1.463536] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>>> [    1.463541] pci_bus 0000:00: root bus resource [mem
>>> 0xc0000000-0xdfffffff]
>>> [    1.463547] pci_bus 0000:00: root bus resource [mem
>>> 0x800000000-0x8ffffffff]
>>>
>>>
>>> So I assume this works, and I am super grateful. I will test it tomorrow
>>> with our Smart NIC.
>>>
>
> Please also check pure branch (unmodified DT) as requested in my
> previous email . According to the bootlog the stall was observed after
> pcie driver init and without latest patch I mentioned. So I'd like to
> make sure that we're on the same side here.
>
>>
>> This doesn't tell you all that much, to be honest. But at least the
>> numbers look sane now, and appear to match the UEFI configuration.
>>
>>> However, we are building a product that obviously requires long term
>>> maintenance, so may I please get your input on a strategy with this?
>>>
>>> If we decide to stick with this driver, would it be easy for things to
>>> become disjointed?
>>>
>>> The hope with going the EFI route is that we could boot "generic" Ubuntu and
>>> CentOS installs, so I guess as long as we keep the DT and the EFKII snapshot
>>> in sync on our side, the risk is low.
>>>
>>
>> I'm afraid you are getting caught in the middle of a philosophical
>> debate here: many engineers that are involved with the Marvell support
>> in Linux feel that a device tree is not something that should be
>> supported long term, and needs to be bundled with the OS. Over the
>> last couple of kernel releases, the Marvell 8040 support was changed
>> in a non-backward compatible manner numerous times.
>>
>
> I think current DT should work with everything >= v4.12. So far
> multiple users were able to install debian with recent fixes, I
> suggest first making sure, what possibly can happen that your setup
> behaves differently. Switching to a8k-ecam-pcie driver is a nice idea,
> but I'm not sure the distros using DT have it.
>
>> This conflicts badly with the idea that the firmware provides the
>> hardware description (using DT or ACPI), and that the contract with
>> the OS is kept by both sides for longer than a single release.
>>
>> So I cannot really answer that question, unfortunately. If you don't
>> intend to use the onboard network controller, you could go the ACPI
>> route, I guess.
>
> FYI. on-board network ACPI support is being upstreamed to the Centos.
>
>>
>> Another problem is that none of this UEFI/ACPI support is upstream in
>> the Tianocore project, and trying random trees left and right doesn't
>> really help when assessing whether a platform is suitable as a long
>> term investment.
>>
>
> There's only single branch recommended in the MacchiatoBin wiki, I
> wouldn't call it 'random'. Entire branch is supposed to land
> eventually in the Tianocore and become the only support. Before end of
> year ~50 patches got there, still some bits are missing, but I think
> we're not that far from desired point. I really want to push it but
> still it requires time I'm personally short of, so I'll appreciate
> understanding.
>

Please don't take this personally. I understand your situation fully,
but that simply means you shouldn't be left on your own working on
this stuff.