summaryrefslogtreecommitdiffstats
path: root/user/bsps/arm/beagle.rst
diff options
context:
space:
mode:
Diffstat (limited to 'user/bsps/arm/beagle.rst')
-rw-r--r--user/bsps/arm/beagle.rst176
1 files changed, 161 insertions, 15 deletions
diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst
index fe2dc6f..55f75c0 100644
--- a/user/bsps/arm/beagle.rst
+++ b/user/bsps/arm/beagle.rst
@@ -2,6 +2,12 @@
.. Copyright (C) 2019 Vijay Kumar Banerjee
+.. _BSP_arm_beagle:
+.. _BSP_arm_beagleboardorig:
+.. _BSP_arm_beagleboardxm:
+.. _BSP_arm_beagleboneblack:
+.. _BSP_arm_beaglebonewhite:
+
beagle
======
@@ -26,7 +32,7 @@ To boot via uboot, the ELF must be converted to a U-Boot image like below:
.. code-block:: none
- arm-rtems5-objcopy hello.exe -O binary app.bin
+ arm-rtems@rtems-ver-major@-objcopy hello.exe -O binary app.bin
gzip -9 app.bin
mkimage -A arm -O linux -T kernel -a 0x80000000 -e 0x80000000 -n RTEMS -d app.bin.gz rtems-app.img
@@ -61,23 +67,39 @@ Add the following to a file named uEnv.txt:
I2C Driver
----------
-The Beagle has the `i2c-0` device registered at initialization. For registering
-`i2c-1` and `i2c-2` ``bbb_register_i2c_1()`` and
-``bbb_register_i2c_2()`` wrapper functions are respectively used.
+The Beagle i2c initialization is based on the device tree. To initialize a i2c
+device, the user has to enable the respective node in the device tree using
+overlays.
-For registering an I2C device with a custom path (say `/dev/i2c-3`) the
-function ``am335x_i2c_bus_register()`` has to be used.
+For registering an I2C device with a custom path (say `/dev/i2c-eeprom`) an
+overlay has to be provided. The overlay must add an additional attribute
+`rtems,path` with the custom path as value to the respective i2c node.
-The function prototype is given below:
+For example,
+
+.. code-block:: none
+
+ /dts-v1/;
+
+ / {
+ compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
-.. code-block:: C
+ fragment@0 {
+ target = <0xffffffff>;
- int am335x_i2c_bus_register(
- const char *bus_path,
- uintptr_t register_base,
- uint32_t input_clock,
- rtems_vector_number irq
- );
+ __overlay__ {
+ compatible = "rtems,bsp-i2c", "ti,omap4-i2c";
+ status = "okay";
+ rtems,path = "/dev/i2c-eeprom";
+ };
+ };
+
+ __fixups__ {
+ i2c0 = "/fragment@0:target:0";
+ };
+ };
+
+The above example registers a custom path `/dev/i2c-eeprom` for i2c0.
SPI Driver
----------
@@ -88,10 +110,134 @@ For registering with a custom path, the ``bsp_register_spi()`` can be used.
The function prototype is given below:
-.. code-block:: C
+.. code-block:: c
rtems_status_code bsp_register_spi(
const char *bus_path,
uintptr_t register_base,
rtems_vector_number irq
);
+
+Debugging using libdebugger
+---------------------------
+
+RTEMS's ``libdebugger`` requires the ARM debug resources be enabled for it to
+work. The TI SOC used on the ``beagleboneblack`` board provides no access for
+software to the ARM defined debug enable signal ``DBGEN``. The signal is
+negated on power up locking software out of the ARM debug hardware. The signal
+can only be accessed via the JTAG interface.
+
+The ``beagleboneblack`` BSP provides a low level solution to enable the
+``DBGEN`` signal via the JTAG interface if the board has the following
+hardware modification installed. The modification requires the addition of two
+small wire links soldered to the pads of the JTAG connect on the underside of
+the board. A small length of fine wire, a fine tip soldering iron, some good
+quality solder and a pair of fine tip pliers are required. If you are new to
+soldering I suggest you find something to practice on first.
+
+The modification details and software driver can be found in the BSP in the
+file ``bsps/arm/beagle/start/bspdebug.c``. The driver is automatically run
+and the ``DBGEN`` is asserted via JTAG when ``libdebugger`` is started.
+
+The modification is:
+
+1. Locate P2 on the bottom side of the board. It is the JTAG connector
+ pads. If you look at the underside of the board with the SD card holder to
+ the right the pads are top center left. There are 20 pads in two
+ columns. The pads are numbered 1 at the top left then 2 top right, 3 is
+ second top on the left, 4 is second top to the right, then the pin number
+ increments as you move left then right down the pads.
+
+2. Connect P2 to P5.
+
+3. Connect P7 to P13.
+
+The resulting wiring is:
+
+.. code-block:: none
+
+ 1 === /--=== 2
+ 3 === | === 4
+ 5 ===--/ === 6
+ 7 ===--\ === 8
+ 9 === | === 10
+ 11 === | === 12
+ 13 ===--/ === 14
+ 15 === === 16
+ 17 === === 18
+ 19 === === 20
+
+.. figure:: ../../../images/user/bbb-p2-debug-mod.jpg
+ :width: 50%
+ :align: center
+ :alt: BeagleBone Black JTAG Hardware Modification
+
+ BeagleBone Black JTAG Hardware Modification
+
+If ``libdebugger`` fails to detect the registers open the ``bspdebug.c``
+source and change ``has_tdo`` to ``1``, save then rebuild and install the
+BSP. This will turn on an internal feeback to check the JTAG logic. Discard
+the edit once the hardware is working.
+
+Debugging Beagle Bone Black using a JTAG debugger and gdb
+---------------------------------------------------------
+
+Debugging a Beagle Bone Black (or variants) is also possible using a hardware
+JTAG debugger. The JTAG is available via P2. The footprint is for an ARM 20 pin
+cTI connector. That connector should be used, if it is necessary to have access
+to commercially available adapters.
+
+For hand-made cables and adapters a standard 1.27mm pitch header and a 0.635mm
+ribbon cable can be much cheaper. But note that even if it looks compatible,
+it's not the same pin out as a ARM Cortex 20 pin connector!
+
+A lot of JTAG adapters that are working together with OpenOCD will work. There
+are also commercially available systems (like Segger J-Link) that work well with
+the Beagle. Note that the JTAG debugger has to be compatible with ARM Cortex A8.
+Cortex M only debuggers (like the Segger J-Link Edu Mini) won't work.
+
+If the debugger offers a gdb server (like OpenOCD or Segger J-Link) the
+following gdb start script can be used:
+
+.. code-block:: none
+
+ define reset
+ echo -- Reset target and wait for U-Boot to start kernel.\n
+ monitor reset
+ # RTEMS U-Boot starts at this address.
+ tbreak *0x80000000
+ # Linux starts here.
+ tbreak *0x82000000
+ continue
+
+ echo -- Disable watchdog.\n
+ set *(uint32_t*)0x44e35048=0xAAAA
+ while (*(uint32_t*)0x44e35034 != 0)
+ end
+ set *(uint32_t*)0x44e35048=0x5555
+ while (*(uint32_t*)0x44e35034 != 0)
+ end
+
+ echo -- Overwrite kernel with application to debug.\n
+ load
+ end
+
+ target remote :2331
+
+Note that you might have to replace the ``monitor reset`` by some other command
+that resets the target using your specific debugger. You also have to replace
+the ``target remote :2331`` to match the port of your gdb server.
+
+The script expects that the Beagle Bone Black starts some application from an SD
+card or from eMMC. It defines a ``reset`` command that does the following:
+
+ * reset the target
+ * let U-Boot run, initialize the base system, load an FDT and an application
+ * break at the application entry point
+ * disable the watchdog
+ * overwrite the application that has been loaded by U-Boot with the application
+ provided as an command line argument to gdb
+
+This method has the advantage that the application is executed in nearly the
+same environment like it would be executed if loaded by U-Boot directly (except
+for the watchdog).