From: Steven A. Falco <sfalco@harris.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] sequoia uarts
Date: Mon, 04 Aug 2008 09:45:02 -0400 [thread overview]
Message-ID: <489707DE.7060201@harris.com> (raw)
In-Reply-To: <20080801203005.BD001248BF@gemini.denx.de>
Wolfgang Denk wrote:
> In message <48936FD4.3010802@harris.com> you wrote:
>
>> I have verified that the Sequoia (440EPx) does not have its UARTs
>> properly configured. The attached patch corrects this by setting three
>> bits in SDR0_PFC1 to enable 4-wire mode, and to select cts/rts
>> functionality for the UARTs. Also, I modified the GPIO settings for
>>
>
> We definitely do NOT want any hardware handshake on the serial
> console. Never.
>
> Best regards,
>
> Wolfgang Denk
>
Perhaps my comments were not clear. Please let me try again: The
schematic for the Sequoia shows two uarts. U-boot leaves the
SDR0_PFC1[U0IM] bit cleared to 0, which means that the 440EPx will only
have one uart, operating in 8-wire mode. So, U-boot does not set the
CPU to the correct mode to enable two uarts. This is independent of
whether you want RTS/CTS or not, and as far as I can see, it must be
fixed if both uart ports are going to work.
This also applies to the GPIOs. They are not set correctly to connect
the uarts to the I/O pins - the wrong functions and polarities are
selected. This too is dictated by the schematic. The wires go where
they go, and the GPIOs should be configured to match the schematic (or
the schematic should be changed to match the software, but we know that
isn't going to happen). :-)
The remaining point is the SDR0_PFC1[U0ME] and SDR0_PFC1[U1ME] bits,
which determine whether the control signals are RTS/CTS or DCD/DSR.
These signals are wired to the DB-9 jacks on pins 7 and 8. According to
the RS232 standard, these pins are RTS/CTS, and there is nothing
software can do to change their meaning.
So, I believe my patch should be applied as written, so that the
software and hardware agree as to function.
That said, /what we choose to do with the lines is up to us/. If we
don't want to enable RTS/CTS processing in the drivers, that is fine.
We can leave the function disabled. But the hardware registers must be
configured to at least match the schematic wiring. Anything else makes
no sense.
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080804/9ff8422c/attachment.htm
next prev parent reply other threads:[~2008-08-04 13:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-01 20:19 [U-Boot-Users] [PATCH] sequoia uarts Steven A. Falco
2008-08-01 20:30 ` Wolfgang Denk
2008-08-04 13:45 ` Steven A. Falco [this message]
2008-08-06 9:46 ` Stefan Roese
2008-08-06 13:14 ` Steven A. Falco
2008-08-06 14:55 ` Stefan Roese
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=489707DE.7060201@harris.com \
--to=sfalco@harris.com \
--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