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

[Simon Glass]

Hi Stephen,

On Mon, Mar 19, 2012 at 6:46 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 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?

That is the whole point of the device tree effort :-)

>
> 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.

That's up to you of course. Our intent is to have a single binary for
each SOC, with the device tree providing all required config.

>
>>> 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.

You would be surprised. With a device tree I can boot mainline
'seaboard' U-Boot on a few things...

I will update the patch and will see if Wolfgang is comfortable with
this new panic mechanism also.

Regards,
Simon