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 peripheral, this may be a job for figuring out the correct overlay and rebuilding the dts from within the tree.. hrmmm. Inferred this entry from other spi dts defs in sys/boot/ofw/dts without much shame about it being the correct part yet. #diff new.dts orig.dts :root:/home:21:47:07:484beaglebone 800,816d799 < /*## >ash XXX frobnicate the pin settings the hard way; i can do without the preprocess, thanks cscope < // replace with an this overlay patch eventially, after carefully reviweing the ds < #define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) < #define OMAP_IOPAD_OFFSET(pa, offset) (((pa) & 0xffff) - (offset)) < #pinmux_spi1_pins { < #pinctrl-single,pins = < < # AM33XX_IOPAD(0x964, PIN_INPUT_PULLUP | MUX_MODE2) eCAP0_in_PWM0_out.spi1_cs1 < # AM33XX_IOPAD(0x990, PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcasp0_aclkx.spi1_sclk < # AM33XX_IOPAD(0x994, PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcasp0_fsx.spi1_d0 - miso < # AM33XX_IOPAD(0x998, PIN_INPUT_PULLUP | MUX_MODE3) /* mcasp0_axr0.spi1_d1 - mosi < # AM33XX_IOPAD(0x99c, PIN_INPUT_PULLUP | MUX_MODE3) /* mcasp0_ahclkr.spi1_cs0 < # < #define PIN_INPUT_PULLUP (INPUT_EN | PULL_UP) < #define PIN_INPUT_PULLDOWN (PULL_ENA | INPUT_EN) < #define INPUT_EN (1 << 5) < #define PULL_ENA (1 << 3) < #define PULL_UP (1 << 4) 818,838d800 < #define MUX_MODE2 2 < #define MUX_MODE3 3 < needed modes: < < PIN_INPUT_PULLUP | MUX_MODE2 = dc -e '16o 2 5 ^ 2 4 ^ 2 ++ p' = 0x32 < PIN_INPUT_PULLDOWN | MUX_MODE3 = dc -e '16o 2 5 ^ 2 3 ^ 3 + + p' = 0x2B < PIN_INPUT_PULLUP | MUX_MODE3 = = dc -e '16o 2 5 ^ 2 4 ^ 3 ++ p' = 0x33 < */ < < pinmux_spi1_pins { < pinctrl-single,pins = < 0x164 0x32 0x190 0x2B 0x194 0x2B 0x198 0x33 0x19C 0x33 >; < < /* what's the rest of this phandle stuff for? < http://elinux.org/Device_Tree_Mysteries#Phandle < Most device trees in Device Tree Syntax (DTS) (see Appendix A) will not contain explicit < phandle properties. The DTC tool automatically inserts the phandle properties when the DTS < is compiled into the binary DTB format. - < - ignore adn dtb generator should write it for me?*/ < }; < /* never again - how do I use the overlays??? */ < 1737,1739c1699 < status = "okay"; /* >ash was disabled */ < pinctrl-names = "default"; /*>ash reference pin config*/ < /*>nope for overlay pinctrl-0 = <&spi1_pins>; */ --- > status = "disabled"; 1742,1749d1701 < fnord-flash@0 { < #address-cells = <1>; < #size-cells = <1>; < compatible = "st,m25p128", "jedec,spi-nor"; < reg = <0>; /* Chip select 0 */ < spi-max-frequency = <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 default; still nervous about rewiring the device tree without supervision. I'm sure that I'm going to leave myself without a main oscilator. *reboot, escape to our loader ( not U-boot,which seems to honor it's own different dts' in /boot/msdos/dts) loader> load -t dtb boot/dtb/out.dtb boot/dtb/out.dtb size=0xcca8 I'll fix loader.conf after I'm more confident about the solution. then from dmesg: 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: ... dev.spibus.0.%pnpinfo: dev.spibus.0.%location: dev.spibus.0.%driver: spibus dev.spibus.0.%desc: OFW SPI bus dev.spibus.%parent: dev.spi.0.%parent: simplebus0 dev.spi.0.%pnpinfo: name=spi@481a0000 compat=ti,omap4-mcspi dev.spi.0.%location: dev.spi.0.%driver: spi dev.spi.0.%desc: TI McSPI controller dev.spi.%parent: ... 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 the 'unknown card' entry. Is it possible to defer the driver load so perhaps i could poke around this at boot time?: dtrace -n 'fbt::*ti_spi*:entry fbt::spibus*:entry' -- -ash
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3b095b47-f3fb-488f-92f3-518e69d282c1>