<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 16, 2018 at 5:16 PM, Marcin Wojtas <span dir="ltr"><<a href="mailto:mw@semihalf.com" target="_blank">mw@semihalf.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Frederik,<br>
<div><div class="gmail-h5"><br>
2018-03-16 14:04 GMT+01:00 Frederik Lotter <<a href="mailto:frederik.lotter@netronome.com">frederik.lotter@netronome.com</a><wbr>>:<br>
><br>
> On Wed, Mar 14, 2018 at 10:56 AM, Frederik Lotter <<a href="mailto:frederik.lotter@netronome.com">frederik.lotter@netronome.com</a><wbr>> wrote:<br>
>><br>
>> On Wed, Mar 14, 2018 at 10:13 AM, Frederik Lotter <<a href="mailto:frederik.lotter@netronome.com">frederik.lotter@netronome.com</a><wbr>> wrote:<br>
>>><br>
>>> On Tue, Mar 13, 2018 at 6:23 PM, Marcin Wojtas <<a href="mailto:mw@semihalf.com">mw@semihalf.com</a>> wrote:<br>
>>>><br>
>>>> Frederic,<br>
>>>><br>
>>>> >>> Please use the size I suggested for the 'reg' property<br>
>>>> >><br>
>>>> >><br>
>>>> >> Sorry I missed that:<br>
>>>> >><br>
>>>> >> [    1.463413] PCI: OF: host bridge /cp0/pcie@0xe0000000 ranges:<br>
>>>> >> [    1.463427] PCI: OF:    IO 0xeff00000..0xeff0ffff -> 0x00000000<br>
>>>> >> [    1.463435] PCI: OF:   MEM 0xc0000000..0xdfffffff -> 0xc0000000<br>
>>>> >> [    1.463442] PCI: OF:   MEM 0x800000000..0x8ffffffff -> 0x800000000<br>
>>>> >> [    1.463481] pci-host-generic e0000000.pcie: ECAM at [mem<br>
>>>> >> 0xe0000000-0xefefffff] for [bus 00-fe]<br>
>>>> >> [    1.463525] pci-host-generic e0000000.pcie: PCI host bridge to bus<br>
>>>> >> 0000:00<br>
>>>> >> [    1.463531] pci_bus 0000:00: root bus resource [bus 00-fe]<br>
>>>> >> [    1.463536] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]<br>
>>>> >> [    1.463541] pci_bus 0000:00: root bus resource [mem<br>
>>>> >> 0xc0000000-0xdfffffff]<br>
>>>> >> [    1.463547] pci_bus 0000:00: root bus resource [mem<br>
>>>> >> 0x800000000-0x8ffffffff]<br>
>>>> >><br>
>>>> >><br>
>>>> >> So I assume this works, and I am super grateful. I will test it tomorrow<br>
>>>> >> with our Smart NIC.<br>
>>>> >><br>
>>>><br>
>>>> Please also check pure branch (unmodified DT) as requested in my<br>
>>>> previous email . According to the bootlog the stall was observed after<br>
>>>> pcie driver init and without latest patch I mentioned. So I'd like to<br>
>>>> make sure that we're on the same side here.<br>
>>><br>
>>><br>
>>> I attached two logs files. The only difference is the one also uses an initrd.<br>
>>><br>
>>> I now have a pcie card in - and it looks much better.<br>
>>><br>
>>> I am starting to feel like this whole exercise is going to discover something unrelated and stupid I have done, so I apologize in advance. Hopefully the journey will help someone else as well.<br>
>>><br>
>>> Any idea what could be failing? I seem to be some issue mounting the root filesystem  (or at the same time). In the initrd case it seems to complain about mmcblk0 (the onboard flash which I do not use).<br>
>>><br>
>>> I attach my grub file just for in case - i am new to grub (Note I hacked 4 entries towards the end).<br>
>><br>
>><br>
>> Here are 3 more logs, I will not send more - but I thought perhaps this could complete the picture.<br>
>><br>
>> 1. One without a PCIe card - successful PCIe init<br>
>><br>
>> 2. One with a card, but with the PCIe probe causing the stall (this is not often seen)<br>
>><br>
>> 3. The other stall, after successful PCIe init<br>
><br>
><br>
> Hi Marcin,<br>
><br>
> I am sure you are quite busy, and I really appreciate all the help I got from you.<br>
><br>
> Please will you have a look at the last two emails (and the attachments) I've sent you, once you have time again. If there is anything I can do that will help you, just let me know. I really need to get this working reliably for us to proceed with the EFI boot route, and since we really need to support generic netboot/ISO installs and images for CentOS and Ubuntu, I think this must be the best way forward.<br>
><br>
<br>
</div></div>I took a look at your logs and it all looks a bit strange. Is it pure<br>
v4.16-rc5? If yes, can you avoid grub and boot directly from shell?<br></blockquote><div><br></div><div>Could you give me a hint how I do this? I am very new to EDK/grub?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Can you share your grub? I'd like to test it in my setup.<br></blockquote><div><br></div><div>Please find the content of my EFI partition and /boot/grub attached. I will really appreciate if you could give it a go.</div><div><br></div><div>I got this grub through apt-get for Ubuntu.</div><div><br></div><div>apt-get install grub-efi-arm64</div><div><br></div><div>Info below:</div><div><br></div><div><div>root@localhost:/boot# apt-get install grub-efi-arm64</div><div>Reading package lists... Done</div><div>Building dependency tree</div><div>Reading state information... Done</div><div>grub-efi-arm64 is already the newest version (2.02~beta2-36ubuntu3.17).</div><div>0 upgraded, 0 newly installed, 0 to remove and 48 not upgraded.</div><div>root@localhost:/boot# uname -a</div><div>Linux localhost.localdomain 4.16.0-rc5-mbcin-netronome-2-dirty #2 SMP PREEMPT Mon Mar 12 14:40:25 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux</div><div>root@localhost:/boot# cat /etc/os-release</div><div>NAME="Ubuntu"</div><div>VERSION="16.04.3 LTS (Xenial Xerus)"</div><div>ID=ubuntu</div><div>ID_LIKE=debian</div><div>PRETTY_NAME="Ubuntu 16.04.3 LTS"</div><div>VERSION_ID="16.04"</div><div>HOME_URL="<a href="http://www.ubuntu.com/">http://www.ubuntu.com/</a>"</div><div>SUPPORT_URL="<a href="http://help.ubuntu.com/">http://help.ubuntu.com/</a>"</div><div>BUG_REPORT_URL="<a href="http://bugs.launchpad.net/ubuntu/">http://bugs.launchpad.net/ubuntu/</a>"</div><div>VERSION_CODENAME=xenial</div><div>UBUNTU_CODENAME=xenial</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Can you please download:<br>
<a href="https://d-i.debian.org/daily-images/arm64/20180314-02:10/netboot/mini.iso" rel="noreferrer" target="_blank">https://d-i.debian.org/daily-<wbr>images/arm64/20180314-02:10/<wbr>netboot/mini.iso</a><br>
burn on stick and install? It's very easy and I use it in my GPU setup<br></blockquote><div><br></div><div>OK I will try this but first I want to redo my environment from scratch so make sure I have not messed up anything.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
on MacchiatoBin.<br>
<br>
Thanks,<br>
Marcin<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
><br>
>><br>
>>><br>
>>>><br>
>>>> ><br>
>>>> > This doesn't tell you all that much, to be honest. But at least the<br>
>>>> > numbers look sane now, and appear to match the UEFI configuration.<br>
>>>> ><br>
>>>> >> However, we are building a product that obviously requires long term<br>
>>>> >> maintenance, so may I please get your input on a strategy with this?<br>
>>>> >><br>
>>>> >> If we decide to stick with this driver, would it be easy for things to<br>
>>>> >> become disjointed?<br>
>>>> >><br>
>>>> >> The hope with going the EFI route is that we could boot "generic" Ubuntu and<br>
>>>> >> CentOS installs, so I guess as long as we keep the DT and the EFKII snapshot<br>
>>>> >> in sync on our side, the risk is low.<br>
>>>> >><br>
>>>> ><br>
>>>> > I'm afraid you are getting caught in the middle of a philosophical<br>
>>>> > debate here: many engineers that are involved with the Marvell support<br>
>>>> > in Linux feel that a device tree is not something that should be<br>
>>>> > supported long term, and needs to be bundled with the OS. Over the<br>
>>>> > last couple of kernel releases, the Marvell 8040 support was changed<br>
>>>> > in a non-backward compatible manner numerous times.<br>
>>>> ><br>
>>>><br>
>>>> I think current DT should work with everything >= v4.12. So far<br>
>>>> multiple users were able to install debian with recent fixes, I<br>
>>>> suggest first making sure, what possibly can happen that your setup<br>
>>>> behaves differently. Switching to a8k-ecam-pcie driver is a nice idea,<br>
>>>> but I'm not sure the distros using DT have it.<br>
>>>><br>
>>>> > This conflicts badly with the idea that the firmware provides the<br>
>>>> > hardware description (using DT or ACPI), and that the contract with<br>
>>>> > the OS is kept by both sides for longer than a single release.<br>
>>>> ><br>
>>>> > So I cannot really answer that question, unfortunately. If you don't<br>
>>>> > intend to use the onboard network controller, you could go the ACPI<br>
>>>> > route, I guess.<br>
>>>><br>
>>>> FYI. on-board network ACPI support is being upstreamed to the Centos.<br>
>>>><br>
>>>> ><br>
>>>> > Another problem is that none of this UEFI/ACPI support is upstream in<br>
>>>> > the Tianocore project, and trying random trees left and right doesn't<br>
>>>> > really help when assessing whether a platform is suitable as a long<br>
>>>> > term investment.<br>
>>>> ><br>
>>>><br>
>>>> There's only single branch recommended in the MacchiatoBin wiki, I<br>
>>>> wouldn't call it 'random'. Entire branch is supposed to land<br>
>>>> eventually in the Tianocore and become the only support. Before end of<br>
>>>> year ~50 patches got there, still some bits are missing, but I think<br>
>>>> we're not that far from desired point. I really want to push it but<br>
>>>> still it requires time I'm personally short of, so I'll appreciate<br>
>>>> understanding.<br>
>>>><br>
>>>> Thanks,<br>
>>>> Marcin<br>
>>>><br>
>>>> ><br>
>>>> ><br>
>>>> >> For example, using the same DT with uboot, it fails:<br>
>>>> >><br>
>>>> >> [    0.294942] sysfs: cannot create duplicate filename<br>
>>>> >> '/bus/platform/devices/<wbr>e0000000.pcie'<br>
>>>> >> [    0.294950] CPU: 2 PID: 1 Comm: swapper/0 Not tainted<br>
>>>> >> 4.16.0-rc5-mbcin-netronome-2-<wbr>dirty #2<br>
>>>> >> [    0.294952] Hardware name: Marvell 8040 MACHIATOBin (DT)<br>
>>>> >> [    0.294955] Call trace:<br>
>>>> >> [    0.294967]  dump_backtrace+0x0/0x150<br>
>>>> >> [    0.294970]  show_stack+0x14/0x20<br>
>>>> >> [    0.294976]  dump_stack+0x98/0xbc<br>
>>>> >> [    0.294980]  sysfs_warn_dup+0x60/0x78<br>
>>>> >> [    0.294983]  sysfs_do_create_link_sd.isra.<wbr>0+0xd8/0xe0<br>
>>>> >> [    0.294986]  sysfs_create_link+0x20/0x40<br>
>>>> >> [    0.294990]  bus_add_device+0x88/0x148<br>
>>>> >> [    0.294993]  device_add+0x394/0x568<br>
>>>> >> [    0.294997]  of_device_add+0x5c/0x70<br>
>>>> >> [    0.295000]  of_platform_device_create_<wbr>pdata+0x80/0xd0<br>
>>>> >> [    0.295003]  of_platform_bus_create+0xdc/<wbr>0x300<br>
>>>> >> [    0.295006]  of_platform_bus_create+0x11c/<wbr>0x300<br>
>>>> >> [    0.295008]  of_platform_populate+0x4c/0xb0<br>
>>>> >> [    0.295014]  of_platform_default_populate_<wbr>init+0xa4/0xc0<br>
>>>> >> [    0.295017]  do_one_initcall+0x38/0x120<br>
>>>> >> [    0.295020]  kernel_init_freeable+0x134/<wbr>0x1d4<br>
>>>> >> [    0.295025]  kernel_init+0x10/0x100<br>
>>>> >> [    0.295028]  ret_from_fork+0x10/0x18<br>
>>>> >><br>
>>>> >> So I think this confirms that the pcie setup is different between EDKII and<br>
>>>> >> uboot (unless I am doing something stupid here).<br>
>>>> >><br>
>>>> ><br>
>>>> > It looks like you have two copies of the pcie node here, no?<br>
>>><br>
>>><br>
>><br>
><br>
</div></div></blockquote></div><br></div></div>