Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context
Klaus Cucinauomo via freebsd-arm <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
> Am 20.09.2020 um 03:32 schrieb Mark Millard <[email protected]>: > > ...So: unrelated fixes. ... > For the u-boot context, my guess is that the patch that > restricted the size of the DMA region to 1 GiByte or so > to allow things to progress there is effectively a work > around that avoids touching another bug(s) some place. > (NetBSD and Linux do not have such a small size limit. > OpenBSD choose its small limit for other reasons.) Ah, O.K., thanks, got it... ..the bug is that dma of 1GB is always safe but there is no "OS-pre-implementation" for 3GB buffer in 64-bit for RPI4… while , the pcie-device itself DOESN`t have the 1GB - limit like other peripherals.. .. NetBSD also did it that (OpenBSD-)way at first , not for other but the same reason, I GUESS(!).. while , as you know,guessing(and dma) isn't really my area of expertise ;-) : https://github.com/NetBSD/src/commit/5cb936da2a4720fa51984394998fa62c62aea7cd#diff-8e16a107fed72481ef0342727619cfa8 : #define BCM2711_DMA_SIZE 0x3c000000 …,( which is 1GB) jmcneill seems to have then added some voodoo in NetBSD : https://github.com/NetBSD/src/commit/9bf4ec11d132c8b296a3926483aa0b8d43fa43ad the Tux has fixed it there : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/arm64/iort.c?h=v5.8&id=bcf876870b95592b52519ed4aafcf9d95999bc9c#n1125 ..they have things like dma_zone or so... So hardcoding the 1GB constraint into https://reviews.freebsd.org/D25219 or give it a fine grain dma range to 3GB should fix it... Since you teamed up with HPS you both now exactly know what to do, please fix it(today of course:-).. (finally yet another flat joke ) Regards _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"