[U-Boot] [PATCH 5/5] tegra: Implement board_pre_console_panic() for Seaboard

Stephen Warren swarren at wwwdotorg.org
Tue Mar 20 02:46:42 CET 2012

On 03/19/2012 07:31 PM, Simon Glass wrote:
> Hi Stephen,
> On Mon, Mar 19, 2012 at 6:22 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 03/19/2012 04:59 PM, Simon Glass wrote:
>>> Hi Stephen,
>>> On Mon, Mar 19, 2012 at 2:18 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>> On 03/19/2012 02:27 PM, Simon Glass wrote:
>>>>> We enable this feature on all UARTs for Seaboard. This ensures that a
>>>>> message is printed if CONFIG_OF_CONTROL is in use and a value device tree
>>>>> is not available.
>>>> Why not just enabled this on UARTD, since that's what Seaboard uses?
>>>> I guess some derivatives do use UARTB too, which makes things quite
>>>> painful. Perhaps at least limit this to UARTB + UARTD, and not all the
>>>> others?
>>> At the moment we can use Seaboard as a generic Tegra2 board, so we
>>> want the widest possible select of UARTs. I think there is one board
>>> that uses A?
>>> Really I would prefer that we explicitly create a generic Tegra2
>>> board, once the fdt stuff is bedded in.
>> Well, one of Wolfgang's main objections was blasting the panic message
>> through all possible UARTs, which might send junk to something other
>> than a debug UART (e.g. machinery and life support systems were
>> mentioned). This change doesn't seem to solve that. For low-level debug
>> like this, shouldn't we just route it to one single UART that the config
>> file selects?
> The objection was that we did it blindly without knowing what ports
> were safe to use. Now it is under board control. In the case of a
> board where we want the pre-console panic function but only want it on
> UARTB we can do that by creating a board file and a config.
> The CONFIG cannot select which UART to use, because we only have one
> config for all the Seaboard variants, and some use different UARTs.
> Only the device tree can tell you which is the console UART. There is
> a bit of a conflict here, but keep in mind we are trying to have a
> single U-Boot binary - anything that relies on a CONFIG will break
> that.

I don't believe there's any specific requirement or decision to have a
single U-Boot binary. Who has decided that and where is the discussion?

Having a single set of sources seems like quite a large step for a
bootloader, and perhaps can be achieved with DT. Building a binary for
each specific debug UART you need (and potentially for many other
things) seems entirely reasonable.

>> We can certainly think about refactoring things into a unified board
>> file, but that seems like something unrelated to do later...
> Yes it is. But we use Seaboard as our base board for all the Tegra2
> board variants. Some use UARTA, C and one uses D. UART D is a pain
> because it is shared with SPI.
> So my preference is to leave it as it is, but if you just want it to
> be D, then we can go with that for now. At least now it is only a
> single line change. Let me know.

That seems safest for now, especially considering that only baseline
Seaboard is actually supported in mainline U-Boot.

More information about the U-Boot mailing list