Date: Tue, 10 Oct 2023 19:46:59 +0200 From: JMT Sihvola <jsihv@gmx.com> To: "Colin S. Gordon" <csgordon@fastmail.com>, freebsd-riscv@freebsd.org Subject: Re: StarFive VisionFive 2 support Message-ID: <trinity-9d21e012-778a-430e-9e03-91b510e23d8e-1696960019023@3c-app-mailcom-bs15> In-Reply-To: <6c0ddf11-b9c9-4861-affc-7f21e82df755@app.fastmail.com> References: <55416c03-c838-46d5-8f18-f6eb1657f4a5@app.fastmail.com> <trinity-2e0070c2-eb6e-4934-ac6b-78688009c627-1696938230097@3c-app-mailcom-bs01> <7f59abe7-11ee-4efe-9688-28e5722fec9a@app.fastmail.com> <trinity-72a4ce22-a269-4916-963b-ae24f5c1410f-1696950977207@3c-app-mailcom-bs09> <6c0ddf11-b9c9-4861-affc-7f21e82df755@app.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 10, 2023, Colin S=2E Gordon wrote: >I agree some clarity on the licensing issue would be nice=2E It seems cle= ar that GPL-only licensed code isn't allowed in the kernel, but if MIT-lice= nsed code (and dual-licensed including an MIT option) is then that would si= mplify things greatly=2E Even GPL-only licensed code seems to be used=2E For instance a file sys/arm64/rockchip/rk3568_combphy=2Ec refers to sys/contrib/device-tree/include/dt-bindings/phy/phy=2Eh =2E=2E=2Ethough this is probably not desirable at all This is one reason why I've assumed being able to use MIT licensed files might be fine enough for headers=2E >I currently don't have proper clock support, though it looks like that pa= rt of your work is under BSD, so I'll grab that rather than writing my own = from scratch=2E I haven't hit the DMA bug you noted yet, but I also haven't= really done much with the filesystem yet (in particular, I haven't done mu= ch *writing* to the disk yet, just basic tests, and haven't built install m= edia yet --- bsdinstall fails for me currently because it can't create file= s it wants in a read-only memory disk)=2E The DMA bug was met already during the initialization of MMC in the boot= =2E But it is dependent on factors related to memory usage, so it's possible that alternative implementations avoid it (=2E=2E=2Ethough it may surface later= )=2E M=2E Horne's bug report I linked includes details about the issue=2E >I guess the other operative question is: which dtb are you using? I see y= ou have one checked in --- where did it come from? OpenBSD for a while only supported one particular dtb which was *not* one of the ones fr= om the StarFive public releases on Github, and I've been working with the one that I know works for OpenBSD=2E I can trace lookup failure f= or the biu and ciu clocks through to a missing property in the dtb I'm using (#clock-names) and then to some kind of misinterpretation I have= n't debugged yet when I manually add that property to the mmc nodes=2E The DTB I use is from Starfive's github (devel branch)=2E As far as I have understood, using DTB files from other projects is OK (and dts files are permissively licensed) =E2=80=93 but again, I'm not sure what the prevaili= ng=20 practices are=2E (there are different DTBs for different revisions of JH7110) I learned it myself hard way during my efforts with JH7100 that switching to the latest DTB available may fix bugs=2E (I tried to parse a DTB file by myself from Starfive's dts files but it turned out that FreeBSD's dtc program had some syntactical features=20 missing and could not do that=2E As far as I recall some developers=20 reported the issue forward) -Jari
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?trinity-9d21e012-778a-430e-9e03-91b510e23d8e-1696960019023>