Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rationalize TF UART usage in platform ports #220

Closed
danh-arm opened this issue Jul 15, 2014 · 2 comments
Closed

Rationalize TF UART usage in platform ports #220

danh-arm opened this issue Jul 15, 2014 · 2 comments

Comments

@danh-arm
Copy link
Contributor

The way that UARTs are used by TF in the FVP and Juno ports is inconsistent. The FVPs have 4 UARTs available for use, UART0 - UART3. Juno also has 4 UARTs but 2 of these are SoC UARTs, which are exposed via connectors on the back panel, and 2 are FPGA UARTs, which are only accessible via headers on the motherboard (J55 and J56).

The current usage is as follows:

FVPs Juno
SCP N/A SoC UART1
BL1/BL2 UART0 FPGA UART0
BL3-1 UART0 FPGA UART0
BL3-2 (TSP) UART1 FPGA UART1
UEFI UART0 SoC UART0
Linux UART0 SoC UART0

The issues with this are as follows:

  • There isn't a good reason why BL1/BL2 use a different UART to UEFI/Linux on Juno. All components on the cold boot path should use the same UART (only one of them will be running at a given time).
  • SoC UART1 on Juno is more accessible than the FPGA UARTs (i.e. is on the back panel). There is a stronger case for TF to use this than SCP (which is closed source).
  • Each independent runtime component should use a separate UART to avoid interleaved output. BL3-1 currently doesn't emit anything at runtime but is likely to in future so we should allow for this.

So the proposed changes are as follows:

FVPs Juno
SCP N/A FPGA UART1*
BL1/BL2 UART0 SoC UART0*
BL3-1 (cold boot) UART0 SoC UART0*
BL3-1 (runtime) UART1* SoC UART1*
BL3-2 (TSP, cold) UART0* SoC UART0*
BL3-2 (TSP, runtime) UART2* FPGA UART0*
UEFI UART0 SoC UART0
Linux UART0 SoC UART0

* = changed UARTs

@danh-arm
Copy link
Contributor Author

I updated the description here to make the distinction between the UARTs used on the cold boot path and the UARTs used at runtime.

For BL3-1 and BL3-2, these UARTs change between cold boot time and runtime. Supporting this requires additional platform hooks in the BL entrypoint (or main function) to allow platform code to re-initialize the console when the BL has finished its part in the cold boot path.

Until this supported properly, an interim solution will be to:

  • Use the BL3-1 cold boot UARTs above for all BL3-1 output. Currently, there is no console output in BL3-1 at runtime anyway.
  • Use the BL3-2 runtime UARTs above for all BL3-2 output.

soby-mathew added a commit to soby-mathew/arm-trusted-firmware that referenced this issue Aug 21, 2014
This patch changes the UART port assignment for various BL stages
so as to make it consistent on the platform ports. The BL1, BL2 and
BL3-1 now uses UART0 on the FVP port and SoC UART0 on the Juno port.
The BL3-2 uses UART2 on the FVP port and FPGA UART0 on the Juno
port.

This provides an interim fix to ARM-software/tf-issues#220 until
support is added for changing the UART port for a BL image between
cold boot and runtime.

Change-Id: Iae5faea90be3d59e41e597b34a902f93e737505a
soby-mathew added a commit to soby-mathew/arm-trusted-firmware that referenced this issue Aug 21, 2014
This patch changes the UART port assignment for various BL stages
so as to make it consistent on the platform ports. The BL1, BL2 and
BL3-1 now uses UART0 on the FVP port and SoC UART0 on the Juno port.
The BL3-2 uses UART2 on the FVP port and FPGA UART0 on the Juno
port.

This provides an interim fix to ARM-software/tf-issues#220 until
support is added for changing the UART port for a BL image between
cold boot and runtime.

Change-Id: Iae5faea90be3d59e41e597b34a902f93e737505a
@athoelke athoelke modified the milestones: vNext, vNext+1 Aug 27, 2014
@athoelke athoelke modified the milestones: vNext+1, vNext Feb 6, 2015
@danh-arm danh-arm modified the milestones: vNext+1, vNext Oct 7, 2015
@soby-mathew
Copy link

An update to the issue description. We decided that the TSP will use the runtime console for all output because of the complexities involved in synchronous and asynchronous initialization of TSP (depending on TSP_INIT_ASYNC build flag).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants