public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 5/5] tegra: Implement board_pre_console_panic() for Seaboard
Date: Mon, 19 Mar 2012 19:46:42 -0600	[thread overview]
Message-ID: <4F67E182.4050208@wwwdotorg.org> (raw)
In-Reply-To: <CAPnjgZ0vSD5qQAookc49E=-1jviuKX4g4fydRf9q59D3_0Gf8A@mail.gmail.com>

On 03/19/2012 07:31 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Mon, Mar 19, 2012 at 6:22 PM, Stephen Warren <swarren@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@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.

  reply	other threads:[~2012-03-20  1:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-19 20:27 [U-Boot] [PATCH 1/5] Revert "Add board_pre_console_putc to deal with early console output" Simon Glass
2012-03-19 20:27 ` [U-Boot] [PATCH 2/5] Add board_panic_no_console() to deal with early critical errors Simon Glass
2012-03-20 22:26   ` Graeme Russ
2012-03-20 23:22     ` Simon Glass
2012-03-20 23:43       ` Graeme Russ
2012-03-21  0:06         ` Simon Glass
2012-03-21  0:34       ` Stephen Warren
2012-03-21  0:36         ` Simon Glass
2012-03-21  9:02   ` Wolfgang Denk
2012-03-21 16:17     ` Simon Glass
2012-03-21 22:48       ` Wolfgang Denk
2012-03-21 23:04         ` Wolfgang Denk
2012-03-19 20:27 ` [U-Boot] [PATCH 3/5] tegra: Export the UART setup function for use by boards Simon Glass
2012-03-21  9:04   ` Wolfgang Denk
2012-03-19 20:27 ` [U-Boot] [PATCH 4/5] tegra: Provide tegra_pre_console_panic() for early panics Simon Glass
2012-03-19 21:16   ` Stephen Warren
2012-03-19 22:55     ` Simon Glass
2012-03-19 20:27 ` [U-Boot] [PATCH 5/5] tegra: Implement board_pre_console_panic() for Seaboard Simon Glass
2012-03-19 21:18   ` Stephen Warren
2012-03-19 22:59     ` Simon Glass
2012-03-20  1:22       ` Stephen Warren
2012-03-20  1:31         ` Simon Glass
2012-03-20  1:46           ` Stephen Warren [this message]
2012-03-20  1:58             ` Simon Glass
2012-03-21  9:08   ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F67E182.4050208@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox