Date: Tue, 1 Mar 2016 07:56:16 +0100 From: =?utf-8?Q?Martin_Waschb=C3=BCsch?= <martin@waschbuesch.de> To: freebsd-arm@freebsd.org Subject: Re: FreeBSD on Utilite (revisited) Message-ID: <A76C3B9D-5B6A-448B-A61F-0445CB1DDE4E@waschbuesch.de> In-Reply-To: <B95CF024-D789-4728-89F6-D74A4B56E20D@freebsd.org> References: <8262C265-A9F6-4336-9A33-4A97BE7451F6@waschbuesch.de> <6531E2F1-0682-4220-B148-BA7061C50B79@waschbuesch.de> <20160229062941.4374611.32643.3487@gmail.com> <DD3A3881-00CC-44E3-B3C2-DBDB629EDC26@waschbuesch.de> <B95CF024-D789-4728-89F6-D74A4B56E20D@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 29.02.2016 um 08:49 schrieb Oleksandr Tymoshenko = <gonzo@freebsd.org>: >=20 >>=20 >> On Feb 28, 2016, at 11:18 PM, Martin Waschb=C3=BCsch = <martin@waschbuesch.de> wrote: >>=20 >>=20 >>> Am 29.02.2016 um 07:29 schrieb Russell Haley <russ.haley@gmail.com>: >>>=20 >>> It seems compulab's imx6 som is called the CM-FX6. There are some = imx6-cm-fx6 and imx6q-cm-fx6 files in their linux kernel on github? >>>=20 >>> = =E2=80=8Ehttps://github.com/utilite-computer/linux-kernel/tree/utilite/dev= el/arch/arm/boot/dts >>=20 >> Thank you, Russ. >>=20 >> There already is a dts file for the cm-fx6 in the FreeBSD kernel = sources >> for instance /usr/src/sys/gnu/dts/arm/imx6q-cm-fx6.dts >>=20 >> However, the same is true for the Wandboard >> /usr/src/sys/gnu/dts/arm/imx6qdl-wandboard.dtsi >> and yet, Crochet uses the files found under >> /usr/src/sys/boot/fdt/dts/arm/ >=20 > In early days of FDT support number of supported ARM boards was really > small and people tended to write their own DTS files from the scratch, > instead of using ones from Linux due to licensing concerns. These > DTS files were placed to boot/dts/fdt. As number of supported hardware > grew it became clear that this practice is a dead end, we can't keep > up with changes provided by vendors. So after some research it was > concluded that we can bring DTS files from Linux. I don't remember > exact reasoning but the gist of it: they're not code, they're set=20 > of facts about hardware. "Upstream" files were placed to gnu/dts. >=20 > Some of the files in boot/dts/fdt are just wrappers around > vendor-provided dts/dtsi files, fixing Linux-specific=20 > idiosyncrasies or adding new nodes. for instances, there > is no PRUSS node in Linux DTS for beaglebone, but=20 > boot/fdt/dts/arm/beaglebone-common.dtsi adds it. >=20 > You should be able to use .dts file in either directory, build system > checks boot/fdt first and then gnu/ AFAIR.=20 Thanks for that explanation. This makes sense now. >>=20 >> So, I went with the wandboard-quad.dts file from there, seeing as it = should be quite similar to my Utilite Pro. >> So far, no luck. Once the loader slurps in the compiled .dtb, the = system hangs with no further sign of activity. >=20 >=20 > Check stdout/stderr settings in =E2=80=9Cchosen=E2=80=9D node. Looks = like > imx6q-cm-fx6.dts uses UART4 for serial output while Wandboard=20 > quad uses UART0. That is a valuable piece of information, thanks! I also noticed that for IMX6 kernel config, ROOTDEV is hardcoded. Maybe = I am overlooking something, but why go to all the length of making sure = u-boot runs and loads ubldr to have loader capabilities and then not = specify the desired rootdev via loader but compile it into the kernel? Obviously, I do not know if the Wandboard supports it, but the Utilite = can boot from either mmc, usb or msata.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A76C3B9D-5B6A-448B-A61F-0445CB1DDE4E>