Revert "Add board_pre_console_putc to deal with early console output"

This patch adds support for console output in the event of a panic() before the console is inited. The main purpose of this is to deal with a very early panic() which would otherwise cause a silent hang.

A new board_pre_console_panic() function is added to the board API. If provided by the board it will be called in the event of a panic before the console is ready. This function should turn on all available UARTs and output the string (plus a newline) if it possibly can.

Signed-off-by Simon Glass <[email protected]>

---

?void panic(const char *fmt, ...)
?{
+ ? ? ? char str[CONFIG_SYS_PBSIZE];
? ? ? ?va_list args;
+
? ? ? ?va_start(args, fmt);
- ? ? ? vprintf(fmt, args);
- ? ? ? putc('\n');
+ ? ? ? vsnprintf(str, sizeof(str), fmt, args);
? ? ? ?va_end(args);

Hi Simon,

Quoted 22 lines · Simon Glass

This patch adds support for console output in the event of a panic() before the console is inited. The main purpose of this is to deal with a very early panic() which would otherwise cause a silent hang.

A new board_pre_console_panic() function is added to the board API. If provided by the board it will be called in the event of a panic before the console is ready. This function should turn on all available UARTs and output the string (plus a newline) if it possibly can.

Signed-off-by Simon Glass <[email protected]>

---

?void panic(const char *fmt, ...)
?{
+ ? ? ? char str[CONFIG_SYS_PBSIZE];
? ? ? ?va_list args;
+
? ? ? ?va_start(args, fmt);
- ? ? ? vprintf(fmt, args);
- ? ? ? putc('\n');
+ ? ? ? vsnprintf(str, sizeof(str), fmt, args);
? ? ? ?va_end(args);

Review

Quoted 8 lines

(quoted diff) +8 -0

+
+ ? ? ? if (gd->have_console) {
+ ? ? ? ? ? ? ? puts(str);
+ ? ? ? ? ? ? ? putc('\n');
+ ? ? ? } else {
+ ? ? ? ? ? ? ? board_pre_console_panic(str);
+ ? ? ? }
+

Would there be benefit in including an option to dump the pre-console buffer (if one is enabled) - I think it's contents could be rather useful in debugging what went wrong...

And something is nagging at me that the API is just 'not right'. I don't know exactly why, but I really don't like how this is plumbed

panic() calls putc() which, if we do not have a console (and we won't in the case of the early panic case we are dealing with), will be put into the pre console buffer (if enabled)

So having panic() call a board specific function to dump the pre console buffer after the ?vprintf() / putc() would achieve the same result (but you need pre console buffer enabled)

So, if CONFIG_PRE_CONSOLE_BUFFER is defined, we could simply add a call to dump_pre_console_buffer() at the end of panic(). But we already have a function to do that - print_pre_console_buffer(). If we added an argument to print_pre_console_buffer() which is a pointer to a 'putc()' type function (NULL meaning the standard putc()) and that function lived in the board files then life would be good. We could also add a call to a setup function so we are not setting up the UARTS every putc (not that performance is a priority at this stage, but some boards might quibble about hitting certain registers continuously)

But what to do if pre console buffer is not defined? The panic message needs to be sent directly to the 'panic UARTS'...

OK, so what about in panic():
?- If gd->have_console is not set:
? ?o call the board specific setup_panic_uarts() ? ?o call print_pre_console_buffer() passing panic_putc() ? ?o call panic_putc() for all characters in str[] ?- If gd->have_console is set:
? ?o call putc() for all characters in str[]

setup_panic_uarts() and panic_putc() are overriden in the board files

Regards,

Graeme

Hi Graeme,

Quoted 12 lines · Graeme Russ

Hi Simon,

OK, so what about in panic():
?- If gd->have_console is not set:
? ?o call the board specific setup_panic_uarts() ? ?o call print_pre_console_buffer() passing panic_putc() ? ?o call panic_putc() for all characters in str[] ?- If gd->have_console is set:
? ?o call putc() for all characters in str[]

Quoted 1 line

setup_panic_uarts() and panic_putc() are overriden in the board files

I think this is where we got to last time.

The act of calling this pre-console panic function is destructive - it may hang the board and output data to UARTs.

I think I understand the scheme you propose. But setup_panic_uarts() puts the board into a funny state (e.g. may set up or change clocks and pinmux). You then need a board_pre_console_putc() to actually output the characters - you don't mention that. That was the patch

that I reverted :-( Yes I understand that you can separate out the UART init from the part that outputs the characters, but does that really help?

To put it another way, I think we need to stick with the idea that this is a panic, not a normal situation. That means that return from

the board panic output function may be difficult or impossible, and so a putc() arrangement is not a good idea.

For example, I have another board on which there are two possible oscillator clock settings - and we don't know which to use, and the arch clock code has not yet been called! In that case I want the board_pre_console_panic() function to output the string using both options, so that one will produce a message for the user (the other will likely produce just a few characters of garbage because the baud rate is wrong). If we output only a single character then the garbage and good characters will be interspersed.

So, can we get away from the idea that this is a reliable and stable way of outputting characters before the console is ready? If you want the pre-console output, I'm sure we can provide a way of accessing it which the board pre-console panic function can use.

Hi Simon,

Quoted 19 lines · Simon Glass

Hi Graeme,

Quoted 12 lines · Graeme Russ

Hi Simon,

OK, so what about in panic():
?- If gd->have_console is not set:
? ?o call the board specific setup_panic_uarts() ? ?o call print_pre_console_buffer() passing panic_putc() ? ?o call panic_putc() for all characters in str[] ?- If gd->have_console is set:
? ?o call putc() for all characters in str[]

Quoted 1 line

setup_panic_uarts() and panic_putc() are overriden in the board files

I think this is where we got to last time.

Quoted 7 lines

The act of calling this pre-console panic function is destructive - it may hang the board and output data to UARTs.

I think I understand the scheme you propose. But setup_panic_uarts() puts the board into a funny state (e.g. may set up or change clocks and pinmux). You then need a board_pre_console_putc() to actually output the characters - you don't mention that. That was the patch

That's panic_putc()

Quoted 6 lines

that I reverted :-( Yes I understand that you can separate out the UART init from the part that outputs the characters, but does that really help?

To put it another way, I think we need to stick with the idea that this is a panic, not a normal situation. That means that return from

Agreed

Quoted 11 lines

the board panic output function may be difficult or impossible, and so a putc() arrangement is not a good idea.

For example, I have another board on which there are two possible oscillator clock settings - and we don't know which to use, and the arch clock code has not yet been called! In that case I want the board_pre_console_panic() function to output the string using both options, so that one will produce a message for the user (the other will likely produce just a few characters of garbage because the baud rate is wrong). If we output only a single character then the garbage and good characters will be interspersed.

Ouch!

Quoted 5 lines

So, can we get away from the idea that this is a reliable and stable way of outputting characters before the console is ready? If you want the pre-console output, I'm sure we can provide a way of accessing it which the board pre-console panic function can use.

OK, add a function to 'normalise' the pre console buffer by moving the characters so the string starts at the beginning of the buffer and then add an extra format tot he start of the panic string :) - But now the panic buffer needs to be bigger :(

OK, maybe leave it up to the board code to dump the pre-console buffer...

I dunno - It all seems a bit 'wrong' somehow

Regards,

Graeme

On Tue, Mar 20, 2012 at 3:26 PM, Graeme Russ <[email protected]> wrote:

Quoted 8 lines

OK, so what about in panic():
- If gd->have_console is not set:
o call the board specific setup_panic_uarts()
o call print_pre_console_buffer() passing panic_putc()
o call panic_putc() for all characters in str[]
- If gd->have_console is set:
o call putc() for all characters in str[]

Quoted 1 line

setup_panic_uarts() and panic_putc() are overriden in the board files

I think this is where we got to last time.

The act of calling this pre-console panic function is destructive - it may hang the board and output data to UARTs.

Quoted 1 line · Simon Glass

On Tue, Mar 20, 2012 at 3:26 PM, Graeme Russ <[email protected]> wrote:

...

Quoted 12 lines

Quoted 9 lines

OK, so what about in panic():
?- If gd->have_console is not set:
? ?o call the board specific setup_panic_uarts() ? ?o call print_pre_console_buffer() passing panic_putc() ? ?o call panic_putc() for all characters in str[] ?- If gd->have_console is set:
? ?o call putc() for all characters in str[]

setup_panic_uarts() and panic_putc() are overriden in the board files

I think this is where we got to last time.

Quoted 2 lines

The act of calling this pre-console panic function is destructive - it may hang the board and output data to UARTs.

Why would it hang? Well, I assume you're talking about hanging before actually emitting the panic text, rather than looping afterwards as a deliberate choice. I'd consider an accidental hang that prevented the message being seen as a bug.

This patch adds support for console output in the event of a panic() before the console is inited. The main purpose of this is to deal with a very early panic() which would otherwise cause a silent hang.

A new board_pre_console_panic() function is added to the board API. If provided by the board it will be called in the event of a panic before the console is ready. This function should turn on all available UARTs and output the string (plus a newline) if it possibly can.

Dear Simon Glass,

Quoted 4 lines · In message <[email protected]> you wrote:

This patch adds support for console output in the event of a panic() before the console is inited. The main purpose of this is to deal with a very early panic() which would otherwise cause a silent hang.

Quoted 4 lines

A new board_pre_console_panic() function is added to the board API. If provided by the board it will be called in the event of a panic before the console is ready. This function should turn on all available UARTs and output the string (plus a newline) if it possibly can.

In addition to the more constructive comments made already by Grame, I object against this patch because I dislike the whole concept.

Quoted 5 lines

+- Pre-console panic():
+ ? ? ? ? ? ? Prior to the console being initialised, console output is
+ ? ? ? ? ? ? normally silently discarded. This can be annoying if a
+ ? ? ? ? ? ? panic() happens in this time. One reason for this might be

True. ?This is the reason why it has always been an important design rule for U-Boot to initialize the console port as soon as possible.

Quoted 6 lines

+ ? ? ? ? ? ? that you have CONFIG_OF_CONTROL defined but have not
+ ? ? ? ? ? ? provided a valid device tree for U-Boot. In general U-Boot's
+ ? ? ? ? ? ? console code cannot resolve this problem, since the console
+ ? ? ? ? ? ? has not been set up, and it may not be known which UART is
+ ? ? ? ? ? ? the console anyway (for example if this information is in
+ ? ? ? ? ? ? the device tree).

Please make up your mind: ?either you CAN initialize the console, then you can use it to output messages in a regular way, or you CANNOT initialize it, in which case you cannot print anything. ?There is no third option.

Quoted 5 lines

+ ? ? ? ? ? ? The solution is to define a function called
+ ? ? ? ? ? ? board_pre_console_panic() for your board, which alerts the
+ ? ? ? ? ? ? user however it can. Hopefuly this will involve displaying
+ ? ? ? ? ? ? a message on available UARTs, or perhaps at least flashing

If you have "available UARTs", you could use this as console, right?

In the previous discussion you explained the situation differently - you were talking about _any_ UARTs that might be present on the hardware, without caring about twhat these might actually be used for.

I explained that such an approach is highly dangerous. ?I do not want you toi set a precedent for such stle and code.

Quoted 7 lines

+ ? ? ? ? ? ? an LED. The function should be very careful to only output
+ ? ? ? ? ? ? to UARTs that are known to be unused for peripheral
+ ? ? ? ? ? ? interfaces, and change GPIOs that will have no ill effect
+ ? ? ? ? ? ? on the board. That said, it is fine to do something
+ ? ? ? ? ? ? destructive that will prevent the board from continuing to
+ ? ? ? ? ? ? boot, since it isn't going to...

Sorry, but this is bogus. Either you know the console port, or you don't. ?If there is a free UART, it might be attached to custome hardware you have no idea about. ?Ditto for GPIOs. ?Please do not meddle with device state in arbitrary ways. ?If there are LED ports on that board that are intended to signalize status information then it makes sense to use these - but do not use any other ports that might be present on the hardware.

Quoted 3 lines

+ ? ? ? ? ? ? The function will need to output serial data directly,
+ ? ? ? ? ? ? since the console code is not functional yet. Note that if

This is broken design. ?If you can initialize the UART as console, then doi so and use it in the regular way.

Quoted 5 lines

+ ? ? ? ? ? ? the panic happens early enough, then it is possible that
+ ? ? ? ? ? ? board_init_f() (or even arch_cpu_init() on ARM) has not
+ ? ? ? ? ? ? been called yet. You should init all clocks, GPIOs, etc.
+ ? ? ? ? ? ? that are needed to get the string out. Baud rates will need
+ ? ? ? ? ? ? to default to something sensible.

Again, this is broken design. ?We cannot try to catch errors sooner and sooner and soner, and if needed initialization steps have not been executed yet, provide additional code for emergency initialization. We have regular console code, and now we have pre_console_*() stuff, and soon we will have pre_pre_pre_pre_pre_pre_pre_pre_console_*() stuff ? NAK.

Just stick to the design principles, and make sure there is as few stuff that could possibly go wrong before console initialization as possible. ?Than all this crap (excuse me, but I don;t find a better word) will not be needed.

I also dislike the modifications to the common code.

I think you are trying to solve an unsolvable problem. ?If you cannot accept that the board gets stuck without printing anything on the debug console port because there are situations when you don't know which port this is, then you simply should _define_ and _document_ a single port as debug console port. ?Then initialize and use this in the regular way. ?If later information (like from a loaded device tree) means the console gets switched to anothe rport, that's OK. That's what Linux will do as well if you assign another console port there.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Gods don't like people not doing much work. People ?who ?aren't ?busy all the time might start to _think_. ?- Terry Pratchett, _Small Gods_

Quoted 5 lines

Please make up your mind: either you CAN initialize the console, then you can use it to output messages in a regular way, or you CANNOT initialize it, in which case you cannot print anything. There is no third option.

Well that is very clear - we cannot. We hit panic() before console_ready() is called.

Quoted 1 line

If you have "available UARTs", you could use this as console, right?

Yes, if we knew which it was.

We know we won't get to console init in this case - there is a panic() that happens first. So the existing pre-console putc() becomes our route to displaying a message. The problem with that is only that the

board init hasn't happened yet, so either the pre-console putc() must init the UARTs or we need a separate init function.

So the existing pre-console putc() can be used, if we can sort out how to make UART init work. Graeme suggested an approach here - I will see if I can make that work.

Quoted 4 lines

So the existing pre-console putc() can be used, if we can sort out how to make UART init work. Graeme suggested an approach here - I will see if I can make that work.

I don't think I will accept any "pre-console putc()". This is such a dirty hack. Either you can initialize and use putc, then use the normal console mechanism for it, or you cannot. And "cannot" means "cannot" here.

Allow boards to call the tegra_setup_uarts() function so that they can set up UARTs on demand. The UART selection enum is moved into the board.h header file so that boards can use this for pre-console panic.

This function is made available to board which want to display a message when a panic() occurs before the console is set up. This would otherwise result in a silent hang or reboot.

Boards should call tegra_pre_console_panic() and pass the UARTs which are available and safe for a message, as well as the selected clock and serial multiplier values. Defaults are available as CONFIG_DEFAULT_NS16550_CLK and CONFIG_DEFAULT_NS16550_MULT.

arch/arm/cpu/armv7/tegra2/board.c +0 -0

arch/arm/cpu/armv7/tegra2/board.c +13 -0

+		NS16550_t regs = (NS16550_t)*uart_addr;
+		const char *s;
+
+		NS16550_init(regs, divisor);
+		for (s = str; *s; s++) {
+			NS16550_putc(regs, *s);
+			if (*s == '\n')
+				NS16550_putc(regs, '\r');
+		}
+		NS16550_putc(regs, '\n');
+		NS16550_putc(regs, '\r');
+	}
+}

Quoted 8 lines · Simon Glass

This function is made available to board which want to display a message when a panic() occurs before the console is set up. This would otherwise result in a silent hang or reboot.

Boards should call tegra_pre_console_panic() and pass the UARTs which are available and safe for a message, as well as the selected clock and serial multiplier values. Defaults are available as CONFIG_DEFAULT_NS16550_CLK and CONFIG_DEFAULT_NS16550_MULT.

...

Quoted 1 line

arch/arm/cpu/armv7/tegra2/board.c +0 -0

...

arch/arm/cpu/armv7/tegra2/board.c

Quoted 8 lines

arch/arm/cpu/armv7/tegra2/board.c +8 -0

+void tegra_pre_console_panic(int uart_ids, unsigned clock_freq,
+ ? ? ? ? ? ? ? ? ? ? ? ? ?unsigned multiplier, const char *str)
+{
+ ? ? int baudrate, divisor;
+ ? ? const u32 *uart_addr;
+
+ ? ? /* Enable all permitted UARTs */
+ ? ? tegra_setup_uarts(uart_ids);

That call honors uart_ids. ...

Quoted 9 lines

+ ? ? /*
+ ? ? ?* Now send the string out all the selected ?UARTs. We don't try all
+ ? ? ?* possible configurations, but this could be added if required.
+ ? ? ?*/
+ ? ? baudrate = CONFIG_BAUDRATE;
+ ? ? divisor = (clock_freq + (baudrate * (multiplier / 2))) /
+ ? ? ? ? ? ? ? ? ? ? (multiplier * baudrate);
+
+ ? ? for (uart_addr = uart_reg_addr; *uart_addr; uart_addr++) {

Shouldn't this loop also honor uart_ids, and skip sending data to UARTS not in uart_ids? Sure, they aren't set up above, but perhaps they were set up elsewhere in the code and hence are capable of sending out data anyway?

Quoted 4 lines

+ ? ? ? ? ? ? NS16550_t regs = (NS16550_t)*uart_addr;
+ ? ? ? ? ? ? const char *s;

arch/arm/cpu/armv7/tegra2/board.c +1 -0

+

arch/arm/cpu/armv7/tegra2/board.c

Quoted 10 lines

arch/arm/cpu/armv7/tegra2/board.c +10 -0

+ ? ? ? ? ? ? NS16550_init(regs, divisor);
+ ? ? ? ? ? ? for (s = str; *s; s++) {
+ ? ? ? ? ? ? ? ? ? ? NS16550_putc(regs, *s);
+ ? ? ? ? ? ? ? ? ? ? if (*s == '\n')
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? NS16550_putc(regs, '\r');
+ ? ? ? ? ? ? }
+ ? ? ? ? ? ? NS16550_putc(regs, '\n');
+ ? ? ? ? ? ? NS16550_putc(regs, '\r');
+ ? ? }
+}

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.

Quoted 3 lines · Simon Glass

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?

Hi Stephen,

Quoted 10 lines · Stephen Warren

Quoted 3 lines · Simon Glass

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.

Quoted 14 lines · Simon Glass

Hi Stephen,

Quoted 10 lines · Stephen Warren

Quoted 3 lines · Simon Glass

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?

Quoted 6 lines

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?

We can certainly think about refactoring things into a unified board file, but that seems like something unrelated to do later...

Hi Stephen,

Quoted 22 lines · Stephen Warren

Quoted 14 lines · Simon Glass

Hi Stephen,

Quoted 10 lines · Stephen Warren

Quoted 3 lines · Simon Glass

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?

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 2 lines

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.

Quoted 37 lines · Simon Glass

Hi Stephen,

Quoted 22 lines · Stephen Warren

Quoted 14 lines · Simon Glass

Hi Stephen,

Quoted 10 lines · Stephen Warren

Quoted 3 lines · Simon Glass

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?

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 8 lines

Quoted 3 lines

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.

Quoted 3 lines

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.

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.