[RTEMS Project] #3784: Beagle BSP: Add a flattened device tree based initialization
RTEMS trac
trac at rtems.org
Thu Aug 15 18:41:04 UTC 2019
#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
More information about the bugs
mailing list