#3784: Beagle BSP: Add a flattened device tree based initialization
---------------------------------+--------------------------------
  Reporter:  Christian Mauderer  |      Owner:  Christian Mauderer
      Type:  project             |     Status:  assigned
  Priority:  normal              |  Milestone:  Indefinite
 Component:  bsps                |    Version:
  Severity:  normal              |   Keywords:  SoC BSP
Blocked By:  3782                |   Blocking:
---------------------------------+--------------------------------
 == Introduction

 RTEMS currently has multiple BSPs for various Beagle Boards:

 - beagleboardorig               ./bsps/arm/beagle
 - beagleboardxm                 ./bsps/arm/beagle
 - beagleboneblack               ./bsps/arm/beagle
 - beaglebonewhite               ./bsps/arm/beagle

 There are a lot of hard coded values in the drivers like the used pins or
 the register addresses. Applications have to initialize the drivers by
 calling special functions like `bbb_register_i2c_1(...)`.

 Other operating systems like Linux or FreeBSD use a flattened device tree
 (FDT) for this kind of stuff. Due to the FDT they are able to support all
 the board variants with only a single BSP.

 Target of this project would be to create a FDT based initialization for
 the Beagle BSPs. Depending on the result it might can be possible to
 eliminate some of the BSPs mentioned above.

 == Work Overview

 RTEMS already supports FDT for other BSPs. So there is no need to add a
 complete FDT library. The library is also already included in Beagle for
 use together with libbsd.

 Roughly the following steps would be necessary:

 - Parse the pinmux settings from FDT and create a two part driver for a
 'pinctrl-single' compatible FDT entry. One part should be generic so that
 it can be used for other BSPs too and one part will have to be device
 specific (similar to FreeBSD or Linux). This would solve #3782.

 - Remove pinmux initialization from all drivers.

 - Initialize drivers based on the FDT (instead of functions like
 bbb_register_i2c_1(...)). This means that a lot of headers with hardcoded
 register addresses will have to be changed.

 - Taking a more detailed look at the FDT what else could be initialized
 from it. Candidates are clocks, RAM size, ...

 - Update the documentation to show the changes.

 - Care should be taken that it is possible to remove drivers in case
 someone wants to write a really small BSP. There are multiple approaches
 for that. See
 https://lists.rtems.org/pipermail/devel/2019-August/027288.html for a
 discussion about that.

 - Make sure there is a reasonable error message if no or an invalid FDT is
 provided.

 == Requirements

 - Minimal requirement for that project is one Beagle variant (e.g. BBB). I
 would suggest more if possible. There also should be a Beagleboard XM
 simulator that can be used as a second variant.

 - Some possibility to debug the application. In this case it should be
 possible to use the simulator for this. But plan enough time to set it up.
 An alternative is a hardware debugger like a J-Link (EDU), some OpenOCD
 based solution like Flyswatter or another debugger solution.

 - Good ability to read C code. This project will need a lot of it to adapt
 the drivers.

 - Basic knowledge about how to use U-Boot. You'll need it for testing
 different FDTs.

--
Ticket URL: <http://devel.rtems.org/ticket/3784>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
_______________________________________________
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Reply via email to