[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-arm
Subject:    Re: Bootable image for Macchatobin Double Shot?
From:       greg () unrelenting ! technology
Date:       2020-04-27 17:16:33
Message-ID: 22fff3856f9f1b5c6e47119bd5eef376 () unrelenting ! technology
[Download RAW message or body]

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ł(a):
>> On 25 Apr 2020, at 19:01, greg@unrelenting.technology wrote:
>>> I've started an attempt at porting the onboard NIC driver last summer:
>>> 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 what
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..

> 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 for
> 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 EDK2
only if it sees that flag?

(Super fun case though: while most of the cards I have don't get replicated
at all, the Radeon HD 7970 gets replicated as *two* devices.)

> 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 Synquacer?

> 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!

---

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

---

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?
Would a USB keyboard interrupt wake it up?
_______________________________________________
freebsd-arm@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"

[prev in list] [next in list] [prev in thread] [next in thread]