FreeBSD on Layerscape/QorIQ LX2160X

[myfreeweb]

On May 23, 2020 1:25:48 AM UTC, Warner Losh <imp at bsdimp.com> wrote:
>On Fri, May 22, 2020 at 7:07 PM Dan Kotowski <dan.kotowski at a9development.com>
>wrote:
>
>> > > > > I spent some time looking at that NetBSD Layerscape code - I
>> couldn't figure out how to add it
>> > > > > trivially to the current HEAD on my own, so I'm looking forward to
>> seeing how we're going to yeet
>> > > > > that in for testing...
>> > > > > Something like this:
>> > > > >
>> https://github.com/myfreeweb/freebsd/commit/6cbdafbc310b9a0fa4d046f71979aa01302e8b0b
>> > > > >
>> https://send.firefox.com/download/ec0419c6d3fa856e/#QOMHO8pBq1dP1K2_4P4CBw
>> > > >
>> > > > https://gist.github.com/agrajag9/b214aa837d0ed6bb14139770ff5835ff
>> > > > Line 404: panic: Misaligned access from kernel space!
>> > > > oops, I actually have to care about the`bytes` parameter..
>> > > > at least I got the ACPI-walking on the first try :)
>> > > >
>> https://send.firefox.com/download/6406af63fee41a8a/#FnEEayn7igQ_eTGs0Wq0uw
>> > >
>> > > https://gist.github.com/agrajag9/b47d63484fa51eed535d8a43625a5276
>> >
>> > hmmm. there's now a pcib2: <PCI-PCI bridge> at device 0.0 on pci1
>> >
>> > and it actually does allocate memory, after the root fails to:
>> >
>> > pcib1: rman_reserve_resource: start=0x670000000, end=0x67003ffff,
>> count=0x40000
>> > pcib1: pci_host_generic_core_alloc_resource FAIL: type=3, rid=28,
>> start=0000000670000000, end=000000067003ffff, count=0000000000040000,
>> flags=4800
>> > pcib2: allocated memory range (0x70040000-0x7007ffff) for rid 1c of
>> pci1:1:0:0
>> >
>> > iiiinteresting. Try to kldload mpr/mps/whatever? Also insert the nvme
>> drive
>>
>> https://gist.github.com/agrajag9/226018f25c9c5dd9c5dec4d5ea1b767d
>>
>> It just kept looping like that for about 5min before I killed it. But it
>> definitely reads the firmware version correctly - it's been on a shelf for
>> a while. But I'm thinking maybe the card isn't initializing right - there's
>> none of the usual output during POST - so I'm going to dig up that PCI
>> power cable and the RX480 tomorrow and try those.
>>
>> As for NVMe, it panics before I get to a shell.
>>
>
>Where?

You can see that in the gist: "NVME polled command failed to complete within 1s"

Same as before (with straight ECAM).

Looks like straight ECAM *is* supposed to work, after all (with limitations on bifurcation or something, I've heard). The code I'm porting from NetBSD does use that same ECAM space when touching non-0 busses.

Whoops, I might've been working on increasing features instead of fixing bugs.. :D

It's odd that what's failing is just polling I/O with the devices, and after successful reads. Does that smell like cache issues or something?