Surefire PRU - Setup.

[Neil Jubinville]

Hi All,

Thanks for all the previous help, I am happy to report that I have a script that will download, install , configure a beaglebone for working pru support.   It does this at the most basic level.  One blinking LED.

Here is how to get a surefire setup if you are just learning about the PRU and want to know you have a working base system.  Once you have a working base you can build your knowledge from there and understand which pieces do what.

1)    Get this image :    https://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz

install it on SD card / flash it to emmc. It is the release I used.

2) Login into your beaglebone black and run:

git clone https://github.com/Neil-Jubinville/pru

3)  Then    cd pru     followed by    ./prep_pru.sh      and that will kickoff the automatic setup.

You can view the script details here:     https://github.com/Neil-Jubinville/pru/blob/master/prep_pru.sh

In a nutshell - it upgrades the kernel to a know working version, rebuilds device tree overlays, disables cape universal,  enables PRU support, loads the uio_pruss module, downloads examples and sets one of them to run at start up.  It will reboot your beaglebone so make your you are watching it start so you can see it blink.

To see it work, ultimately you will need an LED hooked up to P9.27 to ground (and an inline resister likely).   

Thx,

Neil

[din...@gmail.com]

Many thanks for the script. The blinking-led notes for UIO now point to it:

https://github.com/dinuxbg/pru-gcc-examples/tree/master/blinking-led#uio-host-driver

Regards,

Dimitar

[ercola...@gmail.com]

I did notice a few error messages using the OP's disk image + script..
While the script ran, I saw these errors scroll by -- is this something I should ignore?

_________________________________________________________________________
[..]
Selecting previously unselected package linux-image-4.4.27-ti-r62.
(Reading database ... 69584 files and directories currently installed.)
Preparing to unpack .../linux-image-4.4.27-ti-r62_1jessie_armhf.deb ...
Unpacking linux-image-4.4.27-ti-r62 (1jessie) ...
Setting up linux-image-4.4.27-ti-r62 (1jessie) ...
Error! Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.             <--
Please install the linux-headers-4.4.27-ti-r62 package,                                 <--
or use the --kernelsourcedir option to tell DKMS where it's located                     <--
Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.                           <--
Please install the linux-headers-4.4.27-ti-r62 package,                                 <--
or use the --kernelsourcedir option to tell DKMS where it's located                     <--
Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.                    <--
Please install the linux-headers-4.4.27-ti-r62 package,                                 <--
or use the --kernelsourcedir option to tell DKMS where it's located                     <--
update-initramfs: Generating /boot/initrd.img-4.4.27-ti-r62
zz-uenv_txt: Updating /boot/uEnv.txt [uname_r=4.4.27-ti-r62]
Reading package lists... Done
Building dependency tree
[..]
Receiving objects: 100% (8720/8720), 5.30 MiB | 153.00 KiB/s, done.
Resolving deltas: 100% (4381/4381), done.
Checking connectivity... done.
  DTC     src/arm/am437x-gp-evm.dtb
FATAL ERROR: Unrecognized check name "unit_address_vs_reg"              <--
Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed      <--
make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1                        <--
Makefile:84: recipe for target 'all_arm' failed                         <--
make: *** [all_arm] Error 2                                             <--
  DTC     src/arm/am437x-gp-evm.dtb                                     <--
FATAL ERROR: Unrecognized check name "unit_address_vs_reg"              <--
Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed      <--
make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1                        <--
Makefile:90: recipe for target 'install_arm' failed                     <--
make: *** [install_arm] Error 2                                         <--
Cloning into 'pru-gcc-examples'...
remote: Counting objects: 369, done.
[..]
_________________________________________________________________________

The first set of errors looks like the kernel is updated, but the appropriate kernel headers for that kernel aren't installed?
Not sure if that's what's causing the second errors (Unrecognized check name "unit_address_vs_reg").

Are these errors normal, or perhaps versions of things on the net this script depends on have changed over time, causing it to no longer work?

[Greg Ercolano]

On 05/16/17 16:56, ercola...@gmail.com wrote:
> I did notice a few error messages using the OP's disk image + script..
> While the script ran, I saw these errors scroll by -- is this something I should ignore?
> _________________________________________________________________________
> [..]

> Unpacking linux-image-4.4.27-ti-r62 (1jessie) ...
> Setting up linux-image-4.4.27-ti-r62 (1jessie) ...
> Error! Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found. <--
> Please install the linux-headers-4.4.27-ti-r62 package, <--
> or use the --kernelsourcedir option to tell DKMS where it's located <--
> Your kernel headers for kernel 4.4.27-ti-r62 cannot be found. <--
> Please install the linux-headers-4.4.27-ti-r62 package, <--
> or use the --kernelsourcedir option to tell DKMS where it's located <--
> Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found. <--
> Please install the linux-headers-4.4.27-ti-r62 package, <--
> or use the --kernelsourcedir option to tell DKMS where it's located <--

>[..]


I think the solution here would be to include an "apt-get" in the prep script
before this point to install the correct linux-headers-x.x.xxxx package, based
on whatever new kernel was found during the upgrade process.

In my case, after the reboot, I noticed the active kernel was the new one
the prep script downloaded (4.4.27), as reported by 'uname -r'..
so this seemed to be the appropriate command to install those headers:

apt-get install linux-headers-`uname -r`

I'll see if I can work that into the prep_pru.sh script, and supply a patch.
I imagine I'll have to replace the `uname -r` with the downloaded linux image value,
as at that time the script is running, 'uname -r' will report the wrong kernel version.

I should probably re-do the imaging procedure, and re-run the prep script
from scratch with the change applied, as I'm not sure the prep_pru.sh script
is designed to handle being run more than once (at least, not in its current
incarnation, as it appears to append to .bashrc and /etc/rc.local without checking
if the mods are already there..)

Will try to follow up with what I find..

[Greg Ercolano]

On 05/16/17 17:17, Greg Ercolano wrote:
> On 05/16/17 16:56, ercola...@gmail.com wrote:
>> I did notice a few error messages using the OP's disk image + script..

>> [..]
>> Unpacking linux-image-4.4.27-ti-r62 (1jessie) ...
>> Setting up linux-image-4.4.27-ti-r62 (1jessie) ...
>> Error! Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found. <--
>> Please install the linux-headers-4.4.27-ti-r62 package, <--
>> or use the --kernelsourcedir option to tell DKMS where it's located <--
>> Your kernel headers for kernel 4.4.27-ti-r62 cannot be found. <--
>> Please install the linux-headers-4.4.27-ti-r62 package, <--
>> or use the --kernelsourcedir option to tell DKMS where it's located <--
>

> [..]

> In my case, after the reboot, I noticed the active kernel was the new one
> the prep script downloaded (4.4.27), as reported by 'uname -r'..
> so this seemed to be the appropriate command to install those headers:
>
> apt-get install linux-headers-`uname -r`

> [..]

> Will try to follow up with what I find..

Hmm, so after the new kernel headers were installed, I verified
there's now a 'build' link in the modules directory for that kernel version
that wasn't there before:

# ls -la /lib/modules/4.4.*/build
lrwxrwxrwx 1 root root 36 Oct 26 2016 /lib/modules/4.4.27-ti-r62/build -> /usr/src/linux-headers-4.4.27-ti-r62 <--
lrwxrwxrwx 1 root root 35 May 5 2016 /lib/modules/4.4.9-ti-r25/build -> /usr/src/linux-headers-4.4.9-ti-r25

..which is good, because I know building device drivers need that link
to exist.

So I then retried making the project the prep_pru.sh command failed to build,
but still getting these weird errors:

root@beaglebone:~# export DTB=~/dtb-rebuilder/src/arm
root@beaglebone:~# cd /root/dtb-rebuilder/
root@beaglebone:~/dtb-rebuilder# make clean
CLEAN src/arm
root@beaglebone:~/dtb-rebuilder# make

DTC src/arm/am437x-gp-evm.dtb
FATAL ERROR: Unrecognized check name "unit_address_vs_reg" <--
Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed <--
make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1

Makefile:84: recipe for target 'all_arm' failed

make: *** [all_arm] Error 2

Does anyone know the solution for that?

[Robert Nelson]

sudo apt update
sudo apt install device-tree-compiler --reinstall

Which will install "mainline" dtc 1.4.4, no more of our dtc 1.4.1 +
patches.. It's all mainline dtc now!! ;)

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Greg Ercolano]

On 05/16/17 17:36, Greg Ercolano wrote:
> root@beaglebone:~/dtb-rebuilder# make
> DTC src/arm/am437x-gp-evm.dtb
> FATAL ERROR: Unrecognized check name "unit_address_vs_reg" <--
> Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed <--
> make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1
> Makefile:84: recipe for target 'all_arm' failed
> make: *** [all_arm] Error 2
>
> Does anyone know the solution for that?

Google searches weren't helping me solve that one, so I dug into
the Makefile a bit.

Short answer seems to be to change this line in the Makefile:

-DTC_FLAGS += -Wno-unit_address_vs_reg
+#DTC_FLAGS += -Wno-unit_address_vs_reg

..when I did that, it breezed through the build without errors.

Will move onward to try to get an error free result.


DIGRESSION
==========

Regarding figuring out how to solve the above, it was obvious 'make'
wasn't showing the commands being used to build the targets, so I wanted
to see what was going on when it failed.

The Makefile comments indicate there's some kind of convention to keeping
the noise of the build down, using two Makefile variables 'quiet' and 'Q'.

I found I could get make to show the commands being executed by changing
this section of the Makefile:

ifeq ($(KBUILD_VERBOSE),1)
quiet =
Q =
else
- quiet=quiet_
- Q = @
+ quiet=
+ Q =
endif

With that modification, running 'make' showed the full command
being executed. So instead of just showing this:

DTC src/arm/am437x-gp-evm.dtb
FATAL ERROR: Unrecognized check name "unit_address_vs_reg"

..it now showed the full commands being executed:


make ARCH=arm all_arch
cpp -Wp,-MD,src/arm/.am437x-gp-evm.dtb.d.pre.tmp -nostdinc -Iinclude -Isrc/arm -Itestcase-data -undef -D__DTS__ -x assembler-with-cpp -o src/arm/.am437x-gp-evm.dtb.dts.tmp src/arm/am437x-gp-evm.dts ; /usr/bin/dtc -O dtb -o src/arm/am437x-gp-evm.dtb -b 0 -@ -i src/arm -Wno-unit_address_vs_reg -d src/arm/.am437x-gp-evm.dtb.d.dtc.tmp src/arm/.am437x-gp-evm.dtb.dts.tmp ; cat src/arm/.am437x-gp-evm.dtb.d.pre.tmp src/arm/.am437x-gp-evm.dtb.d.dtc.tmp > src/arm/.am437x-gp-evm.dtb.d

FATAL ERROR: Unrecognized check name "unit_address_vs_reg"

There's actually three commands being run in one line there;
cpp, dts, and cat. The 'dts' line is the one that failed:

/usr/bin/dtc -O dtb -o src/arm/am437x-gp-evm.dtb -b 0 -@ -i src/arm -Wno-unit_address_vs_reg -d src/arm/.am437x-gp-evm.dtb.d.dtc.tmp src/arm/.am437x-gp-evm.dtb.dts.tmp

..and there's the "-Wno-unit_address_vs_reg" flag that dtc was
complaining about.

The man page for dtc doesn't describe a -W flag, but I'm assuming
it's a compiler warning flag of some kind, perhaps like gcc's.

[ercola...@gmail.com]

Thanks Robert, so I take it you might be saying that this command:

    apt install device-tree-compiler --reinstall

..could maybe replace all the following code in the OP's "prep_pru.sh" script:

______________________________________________________________________________

#as per rnelson rebuild the dtbs with pru support as out ofthe box it is now longer supported,
# the user needs to choose either uio_pruss or remote proc to enable otherwise it is not enabled.  Strange that no pru support is enabled by default.

#Essentially you need to edit one of the dts for the base dtb.  Hear we edit the basic default dtb.
cd ~/ && git clone https://github.com/RobertCNelson/dtb-rebuilder
export DTB=~/dtb-rebuilder/src/arm
sed -i -e 's/\/\* #include \"am33xx-pruss-uio.dtsi\" \*\//#include \"am33xx-pruss-uio.dtsi\"/'   $DTB/am335x-boneblack.dts
#sed -i -e 's/#dtb=/dtb=am335x-boneblack-emmc-overlay.dtb/'  /boot/uEnv.txt
cd /root/dtb-rebuilder/ && make
cd /root/dtb-rebuilder/ && make KERNEL_VERSION=4.4.27-ti-r62 install
______________________________________________________________________________

His script already runs apt update right at the top, and it is assumed to already be run as root, so the sudo shouldn't be needed)

I've been a C and assembly programmer since the 80's, but all of this with dtc is still pure greek to me.
I'm assuming the original intent was to install the latest git version of the dtc compiler, though I'm not sure what implications the sed command has, so I'd defer to you or the OP's opinions.

Arguably, the best thing would be to offer up a disk image instead of an image with patches applied from live repos.
I'm actually hoping to create such an image once I confirm a blinking light on the board.

[Gary Thomas]

This is just equivalent to 'make V=1'

>
> With that modification, running 'make' showed the full command
> being executed. So instead of just showing this:
>
>
> DTC src/arm/am437x-gp-evm.dtb
> FATAL ERROR: Unrecognized check name "unit_address_vs_reg"
>
>
> ..it now showed the full commands being executed:
>
>
> make ARCH=arm all_arch
> cpp -Wp,-MD,src/arm/.am437x-gp-evm.dtb.d.pre.tmp -nostdinc -Iinclude -Isrc/arm -Itestcase-data -undef -D__DTS__ -x assembler-with-cpp -o src/arm/.am437x-gp-evm.dtb.dts.tmp src/arm/am437x-gp-evm.dts ; /usr/bin/dtc -O dtb -o src/arm/am437x-gp-evm.dtb -b 0 -@ -i src/arm -Wno-unit_address_vs_reg -d src/arm/.am437x-gp-evm.dtb.d.dtc.tmp src/arm/.am437x-gp-evm.dtb.dts.tmp ; cat src/arm/.am437x-gp-evm.dtb.d.pre.tmp src/arm/.am437x-gp-evm.dtb.d.dtc.tmp > src/arm/.am437x-gp-evm.dtb.d
> FATAL ERROR: Unrecognized check name "unit_address_vs_reg"
>
>
> There's actually three commands being run in one line there;
> cpp, dts, and cat. The 'dts' line is the one that failed:
>
> /usr/bin/dtc -O dtb -o src/arm/am437x-gp-evm.dtb -b 0 -@ -i src/arm -Wno-unit_address_vs_reg -d src/arm/.am437x-gp-evm.dtb.d.dtc.tmp src/arm/.am437x-gp-evm.dtb.dts.tmp
>
> ..and there's the "-Wno-unit_address_vs_reg" flag that dtc was
> complaining about.
>
> The man page for dtc doesn't describe a -W flag, but I'm assuming
> it's a compiler warning flag of some kind, perhaps like gcc's.
>

--
Gary Thomas

[Robert Nelson]

Actually this is now fixed with U-Boot overlays. (I just added the pru
options a week or two back)

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

and i've now just pushed the pru options:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options

No rebuilding, just /boot/uEnv.txt editing..

From /boot/uEnv.txt

###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_uio (mainline kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

pru_rproc is enabled by default, just comment the first and un-comment
the second and reboot..

[William Hermans]

On Tue, May 16, 2017 at 7:41 PM, <ercola...@gmail.com> wrote:

I've been a C and assembly programmer since the 80's, but all of this with dtc is still pure greek to me.
I'm assuming the original intent was to install the latest git version of the dtc compiler, though I'm not sure what implications the sed command has, so I'd defer to you or the OP's opinions.

Well device tree overlay source files are not C, or assembly either. Although, you can use C syntax highlighting in your text editor of choice to make your life easier. I tend to view overlay source files more as something like xml, or some form of a markup language. Understanding the source files though just takes time, and knowledge of how pin-muxing, and several hardware aspect on this platform works.

How, I learned how the source files work, was to take one of the Universal IO overlay source files, and deleted everything in it except the main structure, and a single pin. At this point, you see all the different modes a pin can function as, and things become a bit clearer. It also helps to understand the hardware that you're trying to configure. Some of the simpler overlay source files such as for RTC, or 1-wire. Studying these should help one understand some things too. Such as how to load a driver from an overlay file, or how to configure an I2C device bus address from an overlay file. In the end it just takes time.
 

[ercola...@gmail.com]

On 05/16/17 19:21, Greg Ercolano wrote:

> On 05/16/17 17:36, Greg Ercolano wrote:
>> root@beaglebone:~/dtb-rebuilder# make
>>   DTC     src/arm/am437x-gp-evm.dtb
>> FATAL ERROR: Unrecognized check name "unit_address_vs_reg"                 <--
>> Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed         <--
>> make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1
>> Makefile:84: recipe for target 'all_arm' failed
>> make: *** [all_arm] Error 2
>>
>>     Does anyone know the solution for that?
>

>     Short answer seems to be to change this line in the Makefile:
>
> -DTC_FLAGS += -Wno-unit_address_vs_reg
> +#DTC_FLAGS += -Wno-unit_address_vs_reg
>
>     ..when I did that, it breezed through the build without errors.

    OK, things went pretty smoothly after that; I now have
    a blinking LED via PRU control. W00t!

A DISK IMAGE WITH EVERYTHING APPLIED
====================================

    So as to make this easier for others, I've taken a snapshot
    of my entire 4G disk image with the OP's script applied, and
    put the resulting image here:

    http://seriss.com/people/erco/beaglebone/beaglebone-black-surefire--debian-8.4-pru-example--05-16-2017--4gb-erco.img.xz
    SIZE: 973589464 bytes (928M)
    SHASUM: b36840a28618eb8d95545bb367e20212bae74230
    CKSUM: 3178223733 973589464

    Basically write that to an SDHC card and boot it (don't flash),
    login as root and view the /root/README.txt to blink an LED
    via PRU. No external dependencies.

    When done, just run 'halt', and you can revert to your normal
    flashed OS by removing the SDHC from the slot and rebooting.

    If this is popular, I can re-post it as a top level post.

DETAILS
=======

    Breaking that down a bit, I have a BeagleBone Black (BBB) rev C.
    Once the .xz image is downloaded:

        1) unxz the disk image, and write the resulting .img
           to a micro SDHC card that's 4GB or larger.

        2) Put the micro SDHC into the BBB's slot.

        3) Power up the BBB with the micro SD card in the slot.
           *No need* to flash it or hold any buttons down during boot!
           Just do a normal boot with the micro SD card in the slot.

        4) When it boots, login as root. (no password)

        5) Refer to the ~root/README.txt file, but basically in the
           shell, run:

        modprobe uio_pruss
        config-pin overlay BB-BONE-PRU
        cd /root/pru/pru-gcc-examples/blinking-led/host-uio
        ./out/pload ../pru/out/pru-core0.elf ../pru/out/pru-core1.elf

           Those commands should all succeed.
           The last command runs the actual demo on the PRU's; it runs
           for about a minute then exits by itself.

           While it's running, an LED should be blinking at around 2Hz
           if wired between P9.27 and ground thru a 1K resistor under
           control of the PRU.

           When it finishes running, the LED stops blinking and the
           PRUs will stop. You can just run that last command again
           to re-run the demo to get the LED flashing again.

    For step #1, I used an 8GB micro SDHC1 card I bought at the
    Walgreens down the street for $6. These disks are cheap, so buy
    a few so you can boot different OS images easily, and make backups.

    For step #3, I found I could just boot the card without flashing.
    This is *great* because you don't have to wipe your flashed OS.
    You can boot just to test without messing up your installation.

    For step #4, I had my BBB plugged into my router with an ethernet
    cable, and ssh'ed into it as root from one of my other machines
    using the DHCP assigned IP. I assume other techniques work too,
    including the USB cable approach.

    In root's home directory I put a README.txt file that
    explains what to do:
___________________________________________________________________

RUNNING THE EXAMPLE
===================
To blink some LEDs using the PRU, first these preparatory commands
need to have been run since the last boot:

        modprobe uio_pruss
        config-pin overlay BB-BONE-PRU

..and with that, these commands should load up PRU0 and PRU1
with code to blink an LED:

        cd /root/pru/pru-gcc-examples/blinking-led/host-uio
        ./out/pload ../pru/out/pru-core0.elf ../pru/out/pru-core1.elf

Assuming there are no errors, you should see an LED flashing
if connected between GPIO pin P9.27 and ground through an appropriate
current limiting resistor.
___________________________________________________________________

     As an added detail:

* * *
 You can use this wiring diagram for wiring info:
 http://beagleboard.org/static/images/cape-headers.png
 Should that image go stale, holding the BBB with the
 ethernet plug at 12 o'clock, P9 is the connector on
 the left. The lower left pinhole is pin 45 and is GND.
 The pinhole 10 holes up from the lower/left is pin 27
 which is the GPIO output we use. An "ascii art" schematic:

                                 1K
  P9 pin 27 (GPIO_115) --------/\/\/\/------(LED)------+
                                                       |
                                                       |
  P9 pin 45 (GND) -------------------------------------+

 The 1K is perhaps conservative; I decided to err on the side
 of being safe, as I didn't look up the max output current.
 Most people use a transistor to light LEDs from the BBB,
 to avoid over-driving. I did try a 440 ohm and that seemed
 normal, but wasn't sure if that would overdraw the output.
 the BBB's outputs.
_____

     Notes about the disk image:

     While it's pretty much exactly what the OP's script configures,
     I did do a few extra things:

         o I left the OP's script unmodified (git commit 03ece3f),
           but solved the problems I ran into earlier by hand.
           My bash 'history' is in the snapshot; it'll show most
           if not all the commands I ran.

         o I installed the kernel headers for the newer kernel.
           Anyone building device drivers from source needs that.

         o In my case I disabled the OP's mods to /etc/rc.local that
           included the modprobe/config-pin commands on boot;
           I didn't want to hide that from the first time user.
           IMHO it's important developers know what device driver
           is needed and how config-pin works.

         o To free up space so there was more room to install
           packages, and leave some elbow room for development,
           I chose to uninstall x11 and cairo. This freed about
           1/4 of the drive (~500MB). I used:

                  apt-get remove --auto-remove --no-upgrade x11-common
                  apt-get remove --auto-remove --no-upgrade libcairo2
                  apt-get clean

           This removed a lot actually.. most of the GUI stuff.

         o I enlarged the original disk image a bit from 3.5G -> ~4G
           using an fdisk/resize2fs combo so there'd be a little more
           free space on the drive on boot. (I needed that extra space
           to run the OP's script; without it the kernel upgrade
           filled the disk to 100%)

     When the OS boots, you should see almost 1G available:

        # df -h /
        Filesystem      Size  Used Avail Use% Mounted on
        /dev/mmcblk0p1  3.7G  2.7G  768M  78% /

[Greg Ercolano]

On 05/17/17 13:42, William Hermans wrote:

> On Tue, May 16, 2017 at 7:41 PM, <ercola...@gmail.com <mailto:ercola...@gmail.com>> wrote:
> I've been a C and assembly programmer since the 80's, but all of this
> with dtc is still pure greek to me. I'm assuming the original intent
> was to install the latest git version of the dtc compiler, though I'm
> not sure what implications the sed command has, so I'd defer to you or
> the OP's opinions.
>
> Well device tree overlay source files are not C, or assembly either.

> [..] I tend to view overlay source files more as something like xml,

> or some form of a markup language.

________________________________________________________________________________

Thanks -- I appreciate the XML analogy.

I did watch Jason Kridner's videos a few weeks ago which preped me
for learning the device tree file format; I was kinda ready for that
hurdle actually.

What I wasn't ready for was dealing with the internals of the
tools themselves. In the case of dtc, errors like "unit_address_vs_reg"
and things like uboot vs boot, and the language of the various tool
version numbers, what's mainline and what isn't..

Just couldn't grok, after only recently emerging from the wringer
of the last several days.

It's not just dtc I was encountering trouble with; it's been days
of hitting walls with other tools as well; my browser history tells
the sad tail of echo commands causing "kernel oops" errors, the pru
loader tossing up "prussdrv_open() failed" errors.. on and on.

The possible solutions to these issues led everywhere; get this
newer kernel, build this newer module, rebuild blobs, tweak boot flags..
it was supremely overwhelming and depressing.

What's wonderful about starting with the OP's disk image + script
is suddenly the sky cleared; having immediate success (minor bumps)
instead of walls of errors -- I could focus on the task at hand;
writing C code to run the PRUs.

Took hours to achieve success, instead of days achieving none.

BTW, this config-pin tool seems like maybe a way to avoid the
device tree stuff a bit; I see the LED flash example uses this.

Seems promising for my end use case where I just need to assign
GPIO pins to be in/out, and under PRU vs linux control. Its options
are kinda exactly what I need.

> C syntax highlighting in your text editor of choice to make your life easier.

Good idea -- I see there's a few vim syntax files for .dts files, e.g.
https://github.com/vim/vim/blob/master/runtime/syntax/dts.vim

In fact, with the OP's resulting disk image (and the one I posted),
using ':syntax on' in vim while viewing a .dts file seems to be
highlighting meaningfully, apparently due to this file:

/usr/share/vim/vim74/syntax/dts.vim

> Understanding the source files though just takes time, and knowledge
> of how pin-muxing, and several hardware aspect on this platform works.

Do you think the config-pin tool is a way around .dts?

If config-pin didn't exist, I'd probably write it just to avoid
having to manually derive hex codes from diagrams. (Huh, it's
a "dash" script.. cool. Was expecting python..!)

I see also someone made a web page that generates .dts,
using pulldown menus to select GPIO pins and in/out.

I like the promise of config-pin because it can be scripted;
end users could read/tweak its arguments, and a script could
check for errors and take alternative execution paths, and
print meaningful warnings on the user's console, instead of
mixed in with the voluminous output of dmesg and the syslog.

> How, I learned how the source files work, was to take one of the
> Universal IO overlay source files, and deleted everything in it
> except the main structure, and a single pin. At this point,
> you see all the different modes a pin can function as, and things
> become a bit clearer.

Cool -- if config-pin doesn't deliver for me, I'll do that!

Sounds like good advice to start with the dts file.. I take
it you mean the dts equivalent of the /lib/firmware/univ-all-00A0?

> It also helps to understand the hardware that you're trying to
> configure. Some of the simpler overlay source files such as for
> RTC, or 1-wire. Studying these should help one understand some
> things too. Such as how to load a driver from an overlay file,
> or how to configure an I2C device bus address from an overlay file.
> In the end it just takes time.

Interesting; I wasn't aware you can control the load of
device driver modules from dtc files.

I'm kinda used to using modprobe/insmod/rmmod commands
so that I can script them to check for errors. Kernel designers
have different design goals that industrial application devs.

I'll definitely need to learn .dts at some point though.
Perhaps this is as good a place to start as any:
http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf

So I think my actual journey starts here.. the last several
days were all just getting a stable environment, which I'd
hoped the BBB image that shipped with the board would be..!

[William Hermans]

On Wed, May 17, 2017 at 8:35 PM, Greg Ercolano <er...@seriss.com> wrote:

>     . . .

So a lot of text there to "Wade" through so I'll try to answer the questions you have in order. Without the "Sea of text" ;)

I think Universal IO, which includes the shell script config-pin is a really cool tool for getting started. Especially, when all you want to do is get down to writing code for the hardware. However, at the same time I strongly feel that it is not a permanent solution for configuring the hardware, especially for a production system. For many reasons, partly because there can be some glitches, and partly because now we have uboot overlays, that one can load through the second stage bootloader. Which also means, for a production system you can have your pins, and hardware configured exactly how it needs to be. Prior to Linux being up and running. If you script config-pin, this has to be done after Linux is running.

And . . actually, I think that was your only questions. I would like to add some things however. Let's take this:
/* P8_07 (ZCZ ball R7 ) */

P8_07_default_pin: pinmux_P8_07_default_pin {

pinctrl-single,pins = <0x090 0x37>; }; /* Mode 7, Pull-Up, RxActive */

This is just part of configuring a pin. Obviously for P8_07. So for pins that can be operating in GPIO mode. This will be the first entry in any of the universal io overlay files. The first line after the comment is pretty much just a "#define", or a "prototype" definition of the pin in question. Kind of like prototyping a function in C. The second line after the comment is the actual pin information. 0x090 being the pin, which is a kernel pin identifier I think. The second number 0x37 is the mux, and pullup mode( put simply ). You can read the TRM and get a much better explanation of the mux / pullup mode register.

Anyway, check this out. https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/board/am335x-bbw-bbb-base.h#L17

The point here, if you #include Robert's header file, you can use all the BONE_Px_xx #defines in place of the actual "kernel pin value". Which can( does for me ) remove a lot of tedious work trying to memorize, or digging through documentation just to get a pin to work the way you want. Additionally, there is another header file, which #define mux, and other register modes. These two headers alone can take a lot of learning pressure off your shoulders. Then if like me, you do know C very well ( I'm assuming you do ), you can read through these source header files, along with the TRM, or whatever documentation that makes the most sense to you. Suddenly, that light at the end of the tunnel starts to appear. Pullup modes, you simply OR together ( FOO | BAR )

And yeah, I guess there was another question in there. Yes, any dt file starting with "univ "including "univ" or "universal" will be a universal IO related overlay. Some originally written by Charles S( Mug cooler ;) ). or Robert Nelson.

Anyway, right now I am kind of busy with work related code. Bu maybe, sometime soon I can make a working device tree overlay, with an explanation of the file for one pin. Put it on my blog page, and link back to it. The problem with that, is it often takes more work to create a post, than it does to actually just write the code, and *maybe* explain it, if needed.

 

[ercola...@gmail.com]

On Thursday, May 18, 2017 at 3:58:03 PM UTC-7, William Hermans wrote:

So a lot of text there to "Wade" through so I'll try to answer the questions you have in order. Without the "Sea of text" ;)

    No walls of text; OK, will try to keep it shorter.

I think Universal IO, which includes the shell script config-pin is a really cool tool for getting started. Especially, when all you want to do is get down to writing code for the hardware. However, at the same time I strongly feel that it is not a permanent solution for configuring the hardware, especially for a production system. For many reasons, partly because there can be some glitches, and partly because now we have uboot overlays, that one can load through the second stage bootloader. Which also means, for a production system you can have your pins, and hardware configured exactly how it needs to be. Prior to Linux being up and running. If you script config-pin, this has to be done after Linux is running.

    Definitely going to consider those concerns, and keep an eye out for them in my setup.

    In my case I envisioned config-pin in /etc/rc.local to run once, and be able to run it in real time so field personnel can change/experiment. For instance to make a change for a pin to have a pull-up instead of without one.

    I read dev tree files can only be loaded on boot (?), IIRC the binary is loaded ahead of the kernel in ram by the boot loader, so I think dev cycle for dev tree files is harder for the field person, as a recompile + reboot is needed each time. It's hard enough getting field people to just edit config files.

    I'd also like to avoid field people seeing two ways of doing things. During support calls, one could compete with the other in unpredictable ways.. better to provide only one way to do something.

Let's take this:
/* P8_07 (ZCZ ball R7 ) */

P8_07_default_pin: pinmux_P8_07_default_pin {

pinctrl-single,pins = <0x090 0x37>; }; /* Mode 7, Pull-Up, RxActive */

This is just part of configuring a pin. Obviously for P8_07. So for pins that can be operating in GPIO mode. This will be the first entry in any of the universal io overlay files. The first line after the comment is pretty much just a "#define", or a "prototype" definition of the pin in question. Kind of like prototyping a function in C. The second line after the comment is the actual pin information. 0x090 being the pin, which is a kernel pin identifier I think. The second number 0x37 is the mux, and pullup mode( put simply ). You can read the TRM and get a much better explanation of the mux / pullup mode register.

    I see -- I'll do some reading to try to figure out what actually parses this info on boot, as I like to understand what tool/driver is looking at the file I'm configuring, in case I need to RTSL to figure out what's wrong when errors occur. If it's a built in kernel driver (cape driver maybe?)

    I did read petazzoni's "Device Tree For Dummies" last night to try to determine the big picture, but it really lost me somewhere in the middle. Just too much.. stuff.. I didn't want to know or track down. It assumes a knowledge of the modern kernel terminology that I just don't have.

Anyway, check this out. https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/board/am335x-bbw-bbb-base.h#L17 The point here, if you #include Robert's header file, you can use all the BONE_Px_xx #defines in place of the actual "kernel pin value".

    I see, so I take it these two lines would be equivalent, the lower one my construction:

pinctrl-single,pins = <0x090 0x37>; }; /* Mode 7, Pull-Up, RxActive */

pinctrl-single,pins = <BONE_P8_07 0x37>; }; /* Mode 7, Pull-Up, RxActive */

    ..yes, symbols would be better than hex.

Which can( does for me ) remove a lot of tedious work trying to memorize, or digging through documentation just to get a pin to work the way you want. Additionally, there is another header file, which #define mux, and other register modes. These two headers alone can take a lot of learning pressure off your shoulders. Then if like me, you do know C very well ( I'm assuming you do ), you can read through these source header files, along with the TRM, or whatever documentation that makes the most sense to you. Suddenly, that light at the end of the tunnel starts to appear. Pullup modes, you simply OR together ( FOO | BAR )

 

    Yes, it'd be much easier on the eyes if 0x37 could be a few macros OR'ed together instead. Would those values be found in, just guessing: https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/pinctrl/omap.h ? (Same project, different file)

    I wouldn't mind magic numbers if the reference table was in the same document (ascii art preferred to a link, as links go stale).

    For fun, I tried to determine what 0x37 means. You referred to the "TRM", which I take to mean the Sitara Tech Ref Manual (rev c).. that ~2300 page monster! ;) Spent a bit of time in there, but was unable to figure out which table was relevant.

    At first I thought maybe Table 1-236 "PINCTRLn Register Field Descriptions" and Table 1-237 "PINCTRLn Register Pin Multiplexing", but the bits didn't match up. I searched for "mux mode" but that only appeared in the HD video section, and searching for "RxActive" (from the .dts file's comment) without any match at all.

    I googled around and found this spreadsheet which references the AM335x Datasheet, but the link is dead. I found a working link, but was unable to find the table. The speadsheet seems to show some info, so from that I determined 0x37 means "an output with a pullup", which matches the comment. The spreadsheet doesn't say what the lower 3 mode bits are for though. Seems like they weren't sure, as it was left blank.

Anyway, right now I am kind of busy with work related code. Bu maybe, sometime soon I can make a working device tree overlay, with an explanation of the file for one pin. Put it on my blog page, and link back to it. The problem with that, is it often takes more work to create a post, than it does to actually just write the code, and *maybe* explain it, if needed.

    Sounds good -- If you do, I do think comments and inline comment ascii-art tables would help folks. I spent an hour or two floundering around, still not 100% sure what I found.

I do see one of the TI datasheets referred to a windows utility to calculate the pin mux values.. seems that should really be an html/javascript so it can run platform independent, and can be referenced with a link or included locally as an html/js pair. But mainly I don't have a windows box handy ATM.

[ercola...@gmail.com]

On Saturday, May 20, 2017 at 4:42:46 PM UTC-7, ercola...@gmail.com wrote:

On Thursday, May 18, 2017 at 3:58:03 PM UTC-7, William Hermans wrote:

[..]along with the TRM, or whatever documentation that makes the most sense to you. [..]

 

For fun, I tried to determine what 0x37 means. You referred to the "TRM", which I take to mean the Sitara Tech Ref Manual (rev c).. that ~2300 page monster! ;) Spent a bit of time in there, but was unable to figure out which table was relevant.

Oh, OK, I think "the TRM" must refer to this one instead (I think), while bigger (4300 pages), it's a bit easier on my eyes, as it seems to have info more relevant to a software person than this other one I was looking at which seems more hardware somehow. I'm still a bit new to this all.

The latter was the first link google returned when searching for "beaglebone technical reference manual".. they call it the 'system technical reference manual', but seems to be a different thing.

The former also has a good description of the on-chip hardware peripherals (PWM, UART, etc).

[William Hermans]

No, prior to uboot overlays, overlays were loaded from the initrd, at best. Also we need to understand that the board file(also an overlay of sorts - but required )is seperate from all this discussion.

 I do not understand why you would have "field people" playing around with hardware overlays though. Once your hardware is finalized, it should never change. Which is one small reason why I personally find Universal IO unnecessary for my own purposes.

The problem I've seen with explanations, and documentation on device tree, is that no one explains it really well. Additionally, as a new player into device tree overlays. Its not clear where to get information from. See, you need to understand the pin-ctrl subsystem, gpio subsystem . . . list goes one, and on . . .A lot of this information has to be found from the Linux kernel source documentation.HOWEVER, you do not necessarily need to memorize all of this. We ( programmers ) just need a reference that does not goes on, and on for days about silly details we do not need to know to get our jobs done. Nothing like this exists.

Anyway, in order to learn, you need to "do".

[William Hermans]

System reference manual SRM, Technical reference manual TRM.

[Gerald Coley]

I decided not to copy what was in the TRM into the SRM. That is why the SRM is specific to the BBB. And the TRM gets updated failry often by TI.

 

Gerald

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrAaF4Z%2B%3DUZRq%2Bi_oMFRM_K88noC7y5D%3D9MQAkeRUovrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

Greg,

You know what. If I were you, I would get a Beaglebone black or green, and make learning about it your favorite hobby. This way, you could experiment with various things, until you're happy with what you end up using.

If memory is serving me correctly yes, you're using a blue. Yes, yes, but the hardware is largely the same, and most if not all the software will be exactly the same.

So yes, buy a beaglebone, take it home, and start experimenting. Then I would probably not worry about HAVING to have hardware connected up with it. There is a lot you can do by experimenting with software only. How, and where to explore the GPIO subsystem. Which will then lead to being able to tell if you've configured your overlay file at boot correctly. etc, etc.

On Sat, May 20, 2017 at 6:01 PM, Gerald Coley <gco...@emprodesign.com> wrote:

I decided not to copy what was in the TRM into the SRM. That is why the SRM is specific to the BBB. And the TRM gets updated failry often by TI.

 

Gerald

 

 

From: beagl...@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of William Hermans
Sent: Saturday, May 20, 2017 8:00 PM
To: beagl...@googlegroups.com
Subject: Re: [beagleboard] Re: Surefire PRU - Setup.

 

System reference manual SRM, Technical reference manual TRM.

 

On Sat, May 20, 2017 at 5:58 PM, William Hermans <yyr...@gmail.com> wrote:

No, prior to uboot overlays, overlays were loaded from the initrd, at best. Also we need to understand that the board file(also an overlay of sorts - but required )is seperate from all this discussion.

 I do not understand why you would have "field people" playing around with hardware overlays though. Once your hardware is finalized, it should never change. Which is one small reason why I personally find Universal IO unnecessary for my own purposes.

The problem I've seen with explanations, and documentation on device tree, is that no one explains it really well. Additionally, as a new player into device tree overlays. Its not clear where to get information from. See, you need to understand the pin-ctrl subsystem, gpio subsystem . . . list goes one, and on . . .A lot of this information has to be found from the Linux kernel source documentation.HOWEVER, you do not necessarily need to memorize all of this. We ( programmers ) just need a reference that does not goes on, and on for days about silly details we do not need to know to get our jobs done. Nothing like this exists.

Anyway, in order to learn, you need to "do".

 

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrAaF4Z%2B%3DUZRq%2Bi_oMFRM_K88noC7y5D%3D9MQAkeRUovrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a67232f2a5a94c10abc16cc8ff83aa70%40winhexbeus11.winus.mail.

[William Hermans]

By the way these are my own preffered "pin mux mode" "spread sheet" PDF files for working with various pins: https://github.com/wphermans/bb-info/blob/master/BeagleboneBlackP8HeaderPinMuxModes.pdf

I do not recall who made these, but links in the PDF's themselves lead back to who created them. Whom also derived the information in these files from Derrek Molloy.

So I do not claim the material at all. I just wanted a location that was easy for me to find, and would never go away. My git seemed to be as good a place as any, for me.

[William Hermans]

oops, https://github.com/wphermans/bb-info is the top most path . . .

[ercola...@gmail.com]

On Saturday, May 20, 2017 at 5:59:40 PM UTC-7, William Hermans wrote:

System reference manual SRM, Technical reference manual TRM.

     Ah, OK -- it's confusing though; searching for "beaglebone technical reference manual" took me to this beagleboard.org page that has:

        BeagleBone Black System Technical Reference Manual

    Hopefully you can see why I was confused.. I didn't realize the presence of the word "system" made that wrong, but apparently that takes one to "the SRM".

    It's kinda hard to find this TRM when you're on the outside looking in; I looked elsewhere on the beagleboard.org site under "hardware support", "software support", and "Hardware Specs and Materials", and "FAQ" with no luck searching for "technical reference manual" or "SRM" or "TRM". I'd think the abbreviations would at least be in the FAQ. Otherwise, how else would one know?

    Went back to google, and tried including some extra terms that I know are in the TRM, like "interconnects" and "PWM". When I did that, I was able to find what I think is the right pdf file(?):  http://mythopoeic.org/BBB-PRU/am335x_techref.pdf

    I'll see if I can contact the beagleboard.org folks to see if they can include terms TRM and SRM, and perhaps reword the reference to the "System Technical Reference Manual" to instead be, maybe "System Reference Manual (SRM)". There's some email contacts under "About Us", so I'll try that.

[ercola...@gmail.com]

On Saturday, May 20, 2017 at 6:27:31 PM UTC-7, William Hermans wrote:

By the way these are my own preffered "pin mux mode" "spread sheet" PDF files for working with various pins: https://github.com/wphermans/bb-info/blob/master/BeagleboneBlackP8HeaderPinMuxModes.pdf

Thanks! Yes, there's so many of these, some with colors that are kinda hard to read because the colors are a bit too bold.

Great; I'll likely copy/paste that into a .txt file, as I like to edit code in vi over ssh, and pull lines from tables like this with grep. I prefer to develop locally on devices when possible via the terminal, and avoid IDEs and cross compiling from workstations unless there's no other choice.

[ercola...@gmail.com]

On Saturday, May 20, 2017 at 6:14:23 PM UTC-7, William Hermans wrote:

Greg,

You know what. If I were you, I would get a Beaglebone black or green, and make learning about it your favorite hobby. This way, you could experiment with various things, until you're happy with what you end up using.

It's certainly been my hobby for the week. It was ok once I got it working, but I got very close a few times to tossing in the towel when the tools weren't working. Other folks have apparently run into this too and given up, including a friend of mine who turned me on to the BBB before he actually tried it and hit similar walls.

The OP of this thread has been great though -- powered me past those road blocks with the flashed OS and latest debian from TI. Started moving much more quickly after that.
 

If memory is serving me correctly yes, you're using a blue.

Nope, I have a black only. Didn't realize there was a blue, actually. Only knew about the green alternative.

Sorry; I've been using the term "BBB" assuming that referred exclusively to the black. But I can see where if there's also a product called "blue", BBB might refer to that too.. gah. Sorry if that confused anyone; all my replies have been only about the black.

So yes, buy a beaglebone, take it home, and start experimenting. Then I would probably not worry about HAVING to have hardware connected up with it. There is a lot you can do by experimenting with software only. How, and where to explore the GPIO subsystem.

Ya, though I was hitting walls with that too (the black, no hardware attached to it other than the board itself); ram demos weren't running, as they threw up various errors from either the loader tool (open errors) or errors from the echo commands that geneated "write errors" that were trying to trigger device tree files that weren't loading for some reason. Also I tried the GPIO demos without an LED hooked up just to see it run, but was getting similar errors (prussdrv_open() failed, etc), so I didn't even bother with hardware until the OP got me past that.

Hoping to be spinning stepper motors tonight via the PRU.. looking forward to it!

[ercola...@gmail.com]

On Saturday, May 20, 2017 at 5:58:14 PM UTC-7, William Hermans wrote:

 I do not understand why you would have "field people" playing around with hardware overlays though. Once your hardware is finalized, it should never change. Which is one small reason why I personally find Universal IO unnecessary for my own purposes.

I can explain that..

In my case I'm supplying computer software/hardware packages to control old film equipment called optical printers. These are heavy iron monsters with lots of big AC running throughout. They used to be used for special effects, but are now used mainly for film restoration, conversions, and archival. These machines used to be manually run and used mechanical transmissions, and were slowly computerized during the 80's when stepper motor control became popular.

The situation is my software/hardware combo is a starting point, and local engineers usually wire it all up, as there's a lot of AC 115 and 220 being controlled by the interface software.

They will be the ones that define whether they need to assign some of the GPIO bits for input or output, assigning them to either monitor motor homing sensors, or outputs to control custom filter wheels, timing lights and film tension motors. Config files on the computer define what are inputs and outputs my software controls. And during shooting, they might need to add a motor. Or a motor might crap out, and so to limp through production they'd need to disable one of the outputs on the fly and use it for some other purpose.

That's the application, anyway.. it has to be field modifiable, it's not a fixed design, i.e. not a "cape".

I used to (and still use) DOS machines with ISA GPIO cards (usually 8255 based), and DOS software I wrote back in 1987 (mostly C, some 8086 assembly as the DOS device driver for the stepper motors), some of my company's custom hardware, and some third party hardware. And the customer often supplies their own hardware that I help them design by supplying recommended wiring diagrams and sometimes have to get in there with a soldering iron if their own folks aren't available (often hired independent contractors). These are the folks that have to be able to edit files on their own.

I do a lot of other software that pays the bills, but this particular old school project is a bit more hardware oriented, and DOS is showing its age (as are the ISA cards), so I'm hoping to port this whole thing to a beaglebone black, which can replace the DOS machine and 3rd party stepper card which is becoming hard to come by.

[William Hermans]

Sounds like fun. GPIO is super easy on this platform, once you know how the GPIO subsystem works. PWM and ADC is a little more complicated. but not much. PWM can be a bit of a bugger, because some of the examples do not really work( overlays ). With PWM it becomes an exercise of wills, as you the developer find the right example overlay, and have that "aha!" moment. That's the software side of it anyhow.

So we can not really compare this platform to another. Especially the rPI. As the rPI has limited IO capabilities by comparison. Then no pin muxing that I'm aware of. So overlays are quite different. Once you get the various aspect down, it'll get really easy for you. In software.

On the hardware side of things, this platform might be a bit picky. But as long as the engineer pays attention to detail, as one should anyhow. There should not be any problems. Luckily for me, I do not have to deal with the hardware. :)