Date: Sat, 01 Apr 2017 23:00:32 +0000 From: ash <ash@aeria.net> To: <freebsd-arm@freebsd.org> Subject: BBB spi dts follow up Message-ID: <3b095b47-f3fb-488f-92f3-518e69d282c1@aeria.net>
next in thread | raw e-mail | index | archive | help
I decompiled the stock dts to get started with: #dtc -I dtb -O dts /boot/dtb/beaglebone-black.dtb https://lists.freebsd.org/pipermail/svn-src-head/2016-March/084091.html mentions pin configuration and a patchset for lighting up the spi1=20 peripheral, this may be a job for figuring out the correct overlay and=20 rebuilding the dts from within the tree.. hrmmm. Inferred this entry from other spi dts defs in sys/boot/ofw/dts without=20 much shame about it being the correct part yet. #diff new.dts orig.dts =20= :root:/home:21:47:07:484beaglebone 800,816d799 < /*## >ash XXX frobnicate the pin=20 settings the hard way; i can do without the preprocess, thanks cscope < // replace with an this overlay=20 patch eventially, after carefully reviweing the ds < #define AM33XX_IOPAD(pa, val) =20= OMAP_IOPAD_OFFSET((pa), 0x0800) (val) < #define OMAP_IOPAD_OFFSET(pa,=20 offset) (((pa) & 0xffff) - (offset)) < #pinmux_spi1_pins { < #pinctrl-single,pins =3D < < # AM33XX_IOPAD(0x964,=20 PIN_INPUT_PULLUP | MUX_MODE2) eCAP0_in_PWM0_out.spi1_cs1=20 < # AM33XX_IOPAD(0x990,=20 PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcasp0_aclkx.spi1_sclk=20 < # AM33XX_IOPAD(0x994,=20 PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcasp0_fsx.spi1_d0 - miso=20 < # AM33XX_IOPAD(0x998,=20 PIN_INPUT_PULLUP | MUX_MODE3) /* mcasp0_axr0.spi1_d1 - mosi=20 < # AM33XX_IOPAD(0x99c,=20 PIN_INPUT_PULLUP | MUX_MODE3) /* mcasp0_ahclkr.spi1_cs0=20 < #=20 < #define PIN_INPUT_PULLUP =20 (INPUT_EN | PULL_UP) < #define PIN_INPUT_PULLDOWN =20 (PULL_ENA | INPUT_EN) < #define INPUT_EN (1=20= << 5)=20 < #define PULL_ENA (1=20= << 3) < #define PULL_UP (1=20= << 4) 818,838d800 < #define MUX_MODE2 2 < #define MUX_MODE3 3 < needed modes:=20 <=20 < PIN_INPUT_PULLUP | MUX_MODE2 =3D dc=20= -e '16o 2 5 ^ 2 4 ^ 2 ++ p' =3D 0x32 < PIN_INPUT_PULLDOWN | MUX_MODE3 =3D=20= dc -e '16o 2 5 ^ 2 3 ^ 3 + + p' =3D 0x2B < PIN_INPUT_PULLUP | MUX_MODE3 =3D =3D = dc=20 -e '16o 2 5 ^ 2 4 ^ 3 ++ p' =3D 0x33 < */ <=20 < pinmux_spi1_pins {=20 < pinctrl-single,pins =3D <=20 0x164 0x32 0x190 0x2B 0x194 0x2B 0x198 0x33 0x19C 0x33 >; <=20 < /* what's the rest of this=20= phandle stuff for? < =20 http://elinux.org/Device_Tree_Mysteries#Phandle < Most device trees in Device=20= Tree Syntax (DTS) (see Appendix A) will not contain explicit < phandle properties. The DTC=20= tool automatically inserts the phandle properties when the DTS < is compiled into the binary=20= DTB format. - < - ignore adn dtb generator=20= should write it for me?*/ < };=20 < /* never again - how do I use the=20= overlays??? */=20 <=20 1737,1739c1699 < status =3D "okay"; /* >ash was disabled */ < pinctrl-names =3D "default"; /*>ash reference pin=20 config*/ < /*>nope for overlay pinctrl-0 =3D <&spi1_pins>; */ --- > status =3D "disabled"; 1742,1749d1701 < fnord-flash@0 { < #address-cells =3D <1>; < #size-cells =3D <1>; < compatible =3D "st,m25p128",=20 "jedec,spi-nor"; < reg =3D <0>; /* Chip select 0 */ < spi-max-frequency =3D <50000000>; < m25p,fast-read; < }; Rebuild the dts: dtc -I dts -O dtb new.dts > out.dtb cp to /boot/dtb/out.dtb so we can get at it at boottime without overwriting=20= default; still nervous about rewiring the device tree without supervision.=20= I'm sure that I'm going to leave myself without a main oscilator.=20 *reboot, escape to our loader ( not U-boot,which seems to honor it's own=20 different dts' in /boot/msdos/dts)=20 loader> load -t dtb boot/dtb/out.dtb boot/dtb/out.dtb size=3D0xcca8 =20 I'll fix loader.conf after I'm more confident about the solution. then from dmesg:=20 spibus0: <OFW SPI bus> on spi0 spibus0: <unknown card> at cs 0 mode 0 ofwdump -a ... Node 0x68cc: spi@481a0000 Node 0x69f0: fnord-flash@0 ... Good news from in sysctl:=20 ... dev.spibus.0.%pnpinfo:=20 dev.spibus.0.%location:=20 dev.spibus.0.%driver: spibus dev.spibus.0.%desc: OFW SPI bus dev.spibus.%parent:=20 dev.spi.0.%parent: simplebus0 dev.spi.0.%pnpinfo: name=3Dspi@481a0000 compat=3Dti,omap4-mcspi dev.spi.0.%location:=20 dev.spi.0.%driver: spi dev.spi.0.%desc: TI McSPI controller dev.spi.%parent:=20 ... But still no /dev/spi0 device. Any pointers are welcome. Is this the time I write a driver or find one in tree that will attach to=20= the 'unknown card' entry. Is it possible to defer the driver load so perhaps i could poke around=20 this at boot time?: dtrace -n 'fbt::*ti_spi*:entry fbt::spibus*:entry' --=20 -ash
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3b095b47-f3fb-488f-92f3-518e69d282c1>