Date: Thu, 4 Jun 2020 20:11:45 +0200 From: Marcin Wojtas <mw@semihalf.com> To: Greg V <greg@unrelenting.technology> Cc: Mark Murray <markm@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Bootable image for Macchatobin Double Shot? Message-ID: <CAPv3WKdc9HtSEvKfyWAW-atYPmevJb=37-jsZ23EEA8qGKARxQ@mail.gmail.com> In-Reply-To: <CAPv3WKcTG=SwzG5ZZG7Sur4_hjkrdjvQ7tMcsx4LMYB4TepSPg@mail.gmail.com> References: <0532198F-B7DE-46A2-B262-6358EE8370E1@FreeBSD.org> <ED8A3428-E14A-44F6-85D9-A9EEABD364A7@FreeBSD.org> <E2887392-01E4-4ECC-8D0A-4871657D5F8E@FreeBSD.org> <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> <1039B382-2CA4-4F49-9F95-08BD1386A447@FreeBSD.org> <CA07A9C8-267B-4657-B9D1-1F53B62A969B@brickporch.com> <092721df6b1de3e75820acd32ba1b0e7@unrelenting.technology> <e307725bcba79d7c9e0f122ebce26ff1@unrelenting.technology> <c5b816c0d036e1c40f7f1d49fd76e845@unrelenting.technology> <461d8d1da4ad0c03e0f3a256e4ff4b77@unrelenting.technology> <B30FC73E-1721-4E3B-9C12-510EE095413D@FreeBSD.org> <CAPv3WKeWs10RnhPSeGEa481fhA9gHj_qoA8Bqi2cu=5peMoVcA@mail.gmail.com> <22fff3856f9f1b5c6e47119bd5eef376@unrelenting.technology> <CAPv3WKcTG=SwzG5ZZG7Sur4_hjkrdjvQ7tMcsx4LMYB4TepSPg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Greg, =C5=9Br., 29 kwi 2020 o 18:59 Marcin Wojtas <mw@semihalf.com> napisa=C5=82(= a): > > Hi, > > pon., 27 kwi 2020 o 19:16 <greg@unrelenting.technology> napisa=C5=82(a): > > > > April 27, 2020 7:24 PM, "Marcin Wojtas" <mw@semihalf.com> wrote: > > > > > Mark, Greg, > > > > > > Let me chip in, as I noticed my home dir in the logs :) > > > > > > sob., 25 kwi 2020 o 21:21 Mark Murray <markm@freebsd.org> napisa=C5= =82(a): > > >> On 25 Apr 2020, at 19:01, greg@unrelenting.technology wrote: > > >>> I've started an attempt at porting the onboard NIC driver last summ= er: > > >>> https://github.com/myfreeweb/pepevtwo-kmod > > > > > > As you might have noticed, the NIC is pretty complex - one controller > > > consists of a common part with 3 ports capable of working in multiple > > > 1/10G modes, common parsing and buffer management engines. All this > > > has to be put into iflib. I once evaluated expected effort - I'd love > > > to have it in FreeBSD, but it is too big for a hobby project... > > > > LinuxKPI helps with running some of the Linux driver code as-is, for wh= at > > that's worth. > > > > Last time I was looking at the code, what I really didn't understand > > is the mapping between iflib and Linux's API.. > > Maybe it's a path worth exploring, but not sure if it's feasible and I > didn't find examples for the network drivers. > > > > > > > About PCIE controller deficiency - with the Designware IP, the > > > endpoint is replicated on all 32 BUS#0 devices, only if it's a simple > > > present on BDF 0.0.0. This is why we need 'filtering' in the config > > > space accessors. As in Linux ACPI version of the pcie-host-generic fo= r > > > ARM is frozen and no quirks allowed, so the trick with iATU windows > > > was applied in ACPI. It works for cards, such as E1000e, GT730, SATA > > > controllers, etc., but for more complex ones or PCIE switches it's a > > > dead end - this is why the default ACPI settings does not work for > > > your cards. > > > > I've noticed that the "simple" card I have (SATA) is recognized by EFI'= s > > `pci` command as "legacy". Maybe the window quirk could be applied in E= DK2 > > only if it sees that flag? > > > > (Super fun case though: while most of the cards I have don't get replic= ated > > at all, the Radeon HD 7970 gets replicated as *two* devices.) > > Did you see any other issues with the 'pci' command in edk2? If yes, > let's take it offline (or move to edk2 list). > > > > > > There were multiple attempts to handle it in firmware > > > (address translation, address trapping in EL3), but none worked fine. > > > Same issue is problematic on the Socionext Synquacer platform, which > > > uses the same PCIE IP. > > > > Wasn't there some success with some kind of address magic on the Synqua= cer? > > > > > I would really prefer that everyone used the top of tree > > > edk2/edk2-platforms version of the MacchiatoBin port. IMO a good > > > compromise would be having a variable (preferably in the boot menu), > > > that allowed to set non-quirked PCIE ACPI description and SPCR, that > > > would work with the vanilla FreeBSD. I can provide you with the > > > binaries for testing, once submitting patches. What do you think? > > > > Yes, boot menu toggles are my preferred solution too > > (other than the "legacy" check above I guess), > > if you can do it upstream, that would be great! > > > > Not sure when exactly, but I'll inform you directly for testing/review. > > > --- > > > > My builds are already basically top of tree EDK2 + non-quirked tables: > > https://github.com/myfreeweb/edk2-platforms/commits/master > > https://github.com/myfreeweb/edk2/commits/master > > > > however, I still use Marvell's fork of TrustedFirmware-A, > > since TF-A upstream really doesn't work for me: > > - fails to start in weird ways when built with clang > > - fails checksum when booted from an SD card > > - otherwise, proceeds to EDK2, but then > > FreeBSD panics during boot, when sleeping CPUs or something > > (sometimes during "Root mount waiting for: CAM") > > > > And the Marvell version has *none* of these problems. > > I've studied the diff between them in Marvell-related directories, > > found no significant difference o_0 > > > > --- > > Well, I just built today's edk2/edk2-platforms + top of upstream > ARM-TF (a couple of commits above v2.3 tag) and it works flawlessly > with centos/debian and Marvell SDK Linux I have in hand. Afair, for > MacchiatoBin there was no outstanding, not upstreamed code. Update - I had a long debug, as it turned out that on top of the vanilla ATF, the FreeBSD crashes on the SMP boot (no issues with Linux though). But after merging my patch it finally works and can be used: https://github.com/ARM-software/arm-trusted-firmware/commit/03363af888 The SDK did extra modification in the generic psci code, which obviously couldn't be merged upstream, however with above all OSs boot just fine. My todos around McBin and FreeBSD, related to the edk2: - update device tree - with pure v5.6 DT, FreeBSD boots fine. With the older one that is currently in edk2-platforms, it fails to allocate irqs for some devices, so it seems like bindings do not match. - add boot options to withdraw ecam quirk in ACPI and the SPCR hack. Will keep you posted. Regards, Marcin > > > > > In other news, I have the PMU (pmcstat) working with ACPI: > > https://reviews.freebsd.org/D24423 > > > > > > Also, I've noticed suspend-to-RAM support in TF-A code :) > > Does that work on Linux? How would I tell it to wake up > > if there's no power button on the mcbin? > > No. > > > Would a USB keyboard interrupt wake it up? > > I didn't play with suspend to ram on it. For sure it works on A37xx, > I'd need to check the pmops in the EL3 firmware to make entirely sure. > > Best regards, > Marcin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPv3WKdc9HtSEvKfyWAW-atYPmevJb=37-jsZ23EEA8qGKARxQ>