BBB spi dts follow up
ash
ash at aeria.net
Sat Apr 1 23:00:40 UTC 2017
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 at 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 at 481a0000
Node 0x69f0: fnord-flash at 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 at 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
More information about the freebsd-arm
mailing list