I'm going to try starting with Jessie and see if I fare any better. I'll get another data point then at least. Too many variables right now.
On Sunday, November 5, 2017 at 8:59:48 PM UTC-5, Daren Schwenke wrote: > > In case you are wondering why I picked such an ancient cape to model > after, here are the pins consumed by the onboard wifi/bluetooth chip: > That and the BBGW has no HDMI chip, so using the LCD pins instead made a > lot of sense. > > P8_11 WL_SDIO_D1 QEB2B > P8_12 WL_SDIO_D0 QEB2A > P8_14 WL_EN BAT_LED_4 > P8_15 WL_SDIO_D3 PRU_ENC_A > P8_16 WL_SDIO_D2 PRU_ENC_B > P8_17 WL_IRQ BATT_LED_1 > P8_18 WL_SDIO_CLK BATT_LED_2 > P8_26 WL_Level_Shifter_OE BATT_LED_3 > P9_12 BT_EN MDIR_1A > P9_28 BT_AUD_IN SPI1_CS0 > P9_29 BT_AUD_FSYNC SPI1_D0 > P9_30 BT_AUD_OUT SPI1_D1 > P9_31 BT_AUD_CLK SPI1_SCLK > P9_41 WL_SLOW_CLK MOT_STBY > > > On Sunday, November 5, 2017 at 8:53:56 PM UTC-5, Daren Schwenke wrote: >> >> am3358bzcz100 <http://www.ti.com/lit/ds/symlink/am3358.pdf> >> >> BBGW <https://beagleboard.org/green-wireless> >> On Sunday, November 5, 2017 at 7:59:31 PM UTC-5, Charles Steinkuehler >> wrote: >>> >>> On 11/5/2017 5:04 PM, Daren Schwenke wrote: >>> > On Sunday, November 5, 2017 at 1:21:40 PM UTC-5, Daren Schwenke wrote: >>> >> On Sunday, November 5, 2017 at 12:29:42 PM UTC-5, Charles >>> Steinkuehler >>> >> wrote: >>> >> >>> >>> ...and the memory maps should point to the PRU and the chunk of >>> SDRAM >>> >>> allocated by the uio driver: >>> >>> >>> >>> $ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; do echo "$FILE: >>> >>> $(cat $FILE)" ; done >>> >>> /sys/class/uio/uio0/maps/map0/addr: 0x4a300000 >>> >>> /sys/class/uio/uio0/maps/map0/size: 0x80000 >>> >>> /sys/class/uio/uio0/maps/map1/addr: 0x9f780000 >>> >>> /sys/class/uio/uio0/maps/map1/size: 0x40000 >>> >>> >>> >>> debian@beaglebone:~$ for FILE in >>> /sys/class/uio/uio0/maps/map*/[as]* ; >>> >> do echo "$FILE: >>> >>> $(cat $FILE)" ; done >>> >> /sys/class/uio/uio0/maps/map0/addr: >>> >> 0x4a300000 >>> >> /sys/class/uio/uio0/maps/map0/size: >>> >> 0x00080000 >>> >> /sys/class/uio/uio0/maps/map1/addr: >>> >> 0x9c940000 >>> >> /sys/class/uio/uio0/maps/map1/size: >>> >> 0x00040000 >>> >> debian@beaglebone:~$ >>> >> Hmm. Do the leading zero's here matter? >>> >>> The leading zeros don't matter. >>> >>> >>> If any of the above doesn't match, that's probably why things are >>> >>> going wrong. >>> >> >>> >> Um.. the second memory address *is* actually different. Matter? >>> >>> The first memory map (0x4a300000) is the PRU. The second memory map >>> is SDRAM mapped by the UIO driver, and is probably at a different >>> address each boot (or at least it's not unexpected it would be at a >>> different address between major kernel versions). >>> >>> >> In any case, thank you for your expert help Charles. >>> >> I've been stuck at this point for 3 days. >>> >>> I'm wondering if you actually _have_ a PRU (some of the CPU variants >>> do not). Which flavor 'bone are you using? >>> >>> Can you post the full part number of the TI processor (or Octavo SiP)? >>> >>> -- >>> Charles Steinkuehler >>> cha...@steinkuehler.net >>> >> -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
