User Details
- User Since
- Jul 4 2018, 7:23 PM (297 w, 5 d)
Yesterday
Sat, Mar 16
Wed, Mar 13
(The problem this fixes was introduced by me adding profiling to the linker in link_elf_ireloc.)
Tue, Mar 12
By ABI break you mean for riscv64sf getting the old symbol versions? That architecture is dead, we should just delete the dead code in the header.
Oh I had it as an in-progress patch to make these *not* inline-only. I don't think it's a bug that they're only inline, but every other architecture exposes them as actual symbols too and GCC at least relies on that. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272759 (comment 5 in particular) and https://cgit.freebsd.org/src/commit/?id=448c505c33cc334193590f3844406d6a74f26e2a.
Thu, Mar 7
I considered extending the existing riscv_syscon for this purpose, but
it seems better to keep the StarFive/JH7110-specific drivers properly
separated.
Wed, Mar 6
Tue, Mar 5
s/POSIX files/POSIX text files/
What about all the other PCI controller drivers though? Various use ofw_pcib, for example.
Tue, Feb 27
Sat, Feb 24
Fri, Feb 23
Thu, Feb 22
To confirm I understand this:
Initial review comments. Not exhaustive, hard to be for large diffs like this where there are quite a few comments to make, but hopefully I didn't miss anything too fundamental.
Feb 16 2024
Ok, I went and found a copy of the PCI-PCI bridge spec (v1.1), which has this to say:
Feb 15 2024
diff --git a/sys/riscv/sifive/fu740_pci_dw.c b/sys/riscv/sifive/fu740_pci_dw.c index 13937e283042..d0490d6548f2 100644 --- a/sys/riscv/sifive/fu740_pci_dw.c +++ b/sys/riscv/sifive/fu740_pci_dw.c @@ -215,12 +215,6 @@ fupci_phy_init(struct fupci_softc *sc) return (error); }
Well, I isolated it down to a single bootverbose that makes it work, but this just tells me it's almost certainly just because of the delay:
Perhaps worth mentioning HiFive Unmatched somewhere in the description so there's a breadcrumb to follow for where this came from in the first place?
s/VAR/BAR/ in the message.
Feb 13 2024
Feb 12 2024
Doing this for the Unmatched doesn’t seem very useful when we can’t use the SD card for our rootfs due to driver limitations. I’ve generally taken the view that the “correct” way to treat all these dev boards so far is to treat firmware as distinct, whether that means using on-board flash (and a normally-partitioned drive in any form) or a dedicated firmware SD card (and a normally-partitioned drive that’s not the same SD card). The Arm world is a mess with all the special firmware you need, and we should be pushing for standard EFI boot flows where the firmware is part of the board rather than the OS (even if we ship updates to it for convenience).
Feb 10 2024
Feb 9 2024
Feb 7 2024
Landed in ba5777140ec41aae909456f6da77e1b336f52fcb
I suspect this isn't the right approach long-term, but this works in my local testing. This will need U_BOOT_SLAVE_PORTREVISION_2024.01 to be set, but perhaps best to batch that with the patch I have and was trying to test when I encountered this regression?
Feb 6 2024
Feb 5 2024
I've tried to give this a more thorough review and found some issues. Please test it more thoroughly for the various different cases that arise.
Feb 4 2024
(and please also note in the commit message that #ifdef __FreeBSD__ for behavioural changes like this in bootstrap tools is incorrect now that we have cross-building from non-FreeBSD, i.e. that cross-building from macOS and Linux can currently fail when FreeBSD ignores the error)
This is long overdue! Though terminate_cleanup needs unifdef'ing (introduced in the import itself in https://cgit.freebsd.org/src/tree/cddl/contrib/opensolaris/tools/ctf/cvt/ctfconvert.c?id=4cc75139b96639698b4e96da3b60cd3d81e9a959). Note this code itself came into the tree in https://cgit.freebsd.org/src/commit/?id=c01977ed3b6d325bae5de5025eb0c6357ee73be5, which is similarly undocumented in the commit message.
Feb 3 2024
Feb 2 2024
Feb 1 2024
Jan 31 2024
Jan 30 2024
Ping?
This kind of diff is way too big to review, it needs to be broken up. It's easy to mass rename like this but a lot harder to verify that you've actually done the right thing. The second file I picked to look at the diff at was clearly not correct (see the comment linked to this), so that doesn't bode well for the rest of the diff. Also some of the NIC drivers in the tree are really vendor imports, so any changes like this that get made to them should make their way upstream, otherwise there is a risk they got lost. I have not checked if that applies here or not.