This seems to match what GCC does, though I'm not sure why either need it. Both drivers pass both of -lgcc and -lgcc_s, whether building an executable or shared library. Can you elaborate on the exact issue you're seeing without this?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
It surprises me that GNU ld doesn't want to create canonical PLTs, but avoiding them is reasonable; they are to functions what copy relocations are to data.
Wed, May 15
Sat, May 11
It's hard to tell if this was a deliberate design choice or just not thought to be needed when the current UART_FDT_CLASS(_AND_DEVICE) framework was added, but I don't see a good alternative to this. Note that snps and tegra_uart are the only in-tree UART_FDT_CLASS users, and both wrap ns8250.
Thu, May 9
In D45142#1029592, @jhb wrote:Drop md.c change
Fri, May 3
Thu, May 2
Wed, May 1
In D45049#1027191, @jhb wrote:My mental model of what is safe is that it's allowed to move BARs around so long as you disable decoding while you do so, and I'm pretty sure we already do that now to handle FreeBSD kernels (and other OS kernels) that rewrite BARs to size them during boot. We have to avoid trying to register/unregister them while rewriting, and I thought that was driven by if the I/O space was enabled. (See how update_bar_address makes the register_bar call conditional on encoding being enabled.) It sounds like u-boot is just buggy here in that it isn't disabling decoding while it messes with the BARs. This idea is ok though. I wonder if FreeBSD/amd64 boots with this set to true. :)
I believe it's also legal to go and map two BARs to overlap so long as you don't try to access the overlapping range when that's the case? QEMU just maintains a list of PCI BARs and goes for the first one in the list that matches. Allocating the big chunk of MMIO memory statically at the start and just maintaining the list layered on top in PCI code as you mess with BARs seems like it would be a simple, more general fix, and should perform just fine? (Though passthrough may well be "fun" as you mention)
Thu, Apr 25
My opinion is that, whilst they are by no means completely unambiguous and fully descriptive, picking a value that's close to right so the user has some idea what the error was even in the absence of error messages is better than just using a hard-coded wholly-meaningless 1 everywhere, as will inevitably happen (and already does when not using sysexits) as a result of this.
Wed, Apr 24
Apr 19 2024
In D44883#1023197, @kib wrote:Does it matter/used on arm64 and risc-v? I remember that psABIs require nx stack always for them. It might be that some (old ?) linker complained about the note on these arches.
Apr 8 2024
Apr 7 2024
Why do we need a copy of this code rather than just tweaking bsdconfig to support this?
Mar 27 2024
Mar 22 2024
Mar 18 2024
Mar 16 2024
Mar 13 2024
(The problem this fixes was introduced by me adding profiling to the linker in link_elf_ireloc.)
Mar 12 2024
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.
In D44331#1011093, @brooks wrote:In D44331#1011041, @jrtc27 wrote: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.
Ah, I'll grab that and apply it.
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.
Mar 7 2024
I considered extending the existing riscv_syscon for this purpose, but
it seems better to keep the StarFive/JH7110-specific drivers properly
separated.
Mar 6 2024
In D44207#1009367, @jhb wrote:ofw_pcib doesn't pass child resources up to simplebus for allocation or activation, it uses bus_space_map directly with a new-bus method to get the bus_space_tag. I think this might be the only one passing SYS_RES_IOPORT up to simplebus and that if this works we might be able to remove all SYS_RES_IOPORT support from simplebus.
Mar 5 2024
s/POSIX files/POSIX text files/
What about all the other PCI controller drivers though? Various use ofw_pcib, for example.
Feb 27 2024
Feb 24 2024
Feb 23 2024
Feb 22 2024
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); }
In D40474#1001972, @ehem_freebsd_m5p.com wrote:@jrtc27 not being on intimate terms with the GICv3 implementation and lacking hardware to confirm how things work, I've got no idea what to do. What I do know is the extra PIC for this device never gets into sc->gic_children and therefore the loop in gic_v3_init_secondary() doesn't work for this device.
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
In D43849#1000411, @mhorne wrote:In D43849#1000334, @jrtc27 wrote: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).
I really don't have the Unmatched in mind here; on that board it is easiest to use the memstick installer on a USB, and that's what I recommended in the wiki instructions. In other words, driver issues notwithstanding, I still wouldn't recommend GENERICSD for that board.
The problem I am trying to solve here is more related to the VF2, and conceivably other smaller SBCs where root-and-firmware-on-SD is desirable/common. Even in this development stage, trying to prep an SD card for this board is non-trivial. If I dd the GENERICSD image, I then need to rewrite the partition table in order to insert the firmware partitions at the correct indices (gpart cannot modify a partition's index). So, reserving these partitions is a pragmatic choice aiming to reduce the number of user-required steps to install with GENERICSD.
Btw, the choice to use hifive-fsbl and hifive-bbl as the default types is somewhat arbitrary. gpart has these type aliases, and the Unleashed came first of all, so it seems a fine choice.
In D43849#1000398, @manu wrote:In D43849#1000334, @jrtc27 wrote: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.
Which driver ? ours ?
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
In D43806#999575, @jhb wrote:s/SYS_RES_BUS/PCI_RES_BUS/ in commit log
Feb 9 2024
Feb 7 2024
Landed in ba5777140ec41aae909456f6da77e1b336f52fcb
In D43784#998561, @markj wrote:In D43784#998554, @jrtc27 wrote:In D43784#998538, @jrtc27 wrote: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?
FYI this is https://reviews.freebsd.org/D43785. I don't mind bumping the version again, but it does seem a little silly.
Oh, yes. Would you like to merge the patches and push? If not I'll take care of it now.
In D43784#998538, @jrtc27 wrote: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?
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
In D40474#998233, @ehem_freebsd_m5p.com wrote:@jrtc27 I was hoping for an answer to my question before doing anything.
I lack appropriate hardware to confirm this, but I suspect gic_v3_init_secondary() was already being called a second time for systems with both a normal PIC and a MSI PIC. As long as both were GICv3 implementations and one was a direct child of the other, the loop at the end of gic_v3_init_secondary() was doing this.
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.