linux-kernel - Re: [PATCH] ARM: PL011: add support for extended FIFO-size of PL011-r1p5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5193164E.6050400@wwwdotorg.org>
Date:	Tue, 14 May 2013 22:59:58 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Jongsung Kim <neidhard.kim@....com>
CC:	'Russell King' <linux@....linux.org.uk>,
	'Greg Kroah-Hartman' <gregkh@...uxfoundation.org>,
	jslaby@...e.cz, linux-serial@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] ARM: PL011: add support for extended FIFO-size of PL011-r1p5

On 05/14/2013 07:00 PM, Jongsung Kim wrote:
> Stephen Warren <swarren@...dotorg.org> :
>> Looking at BCM2835-ARM-Peripherals.pdf (i.e. the public documentation for
>> the BCM2835 chip), I see:
>>
>> =====
>> The UART provides:
>> * Separate 16x8 transmit and 16x12 receive FIFO memory.
>> ...
>> For the in-depth UART overview, please, refer to the ARM PrimeCell UART
>> (PL011) Revision: r1p5 Technical Reference Manual.
>> =====
>>
>> That seems to imply that not all r1p5 PL011s actually have a depth-32 FIFO.
>> Perhaps this is a configurable property of the IP block, not something that
>> all r1p5 have?
> 
> All r1p5 have 32-byte FIFO depth and it's not configurable. From the PL011
> TRM:
> 
> r1p4-r1p5	Contains the following differences in functionality:
> 		* The receive and transmit FIFOs are increased to a depth of 32.
> 		* The Revision field in the UARTPeriphID2 Register on page 3-24
> 		  bits [7:4] now reads back as 0x3.

Well, that certainly isn't true in practice. I think we should revert
this commit until we can determine what the problem is.

I validated that the periphid register in HW contains the r1p5 revision
(3), and the pcellid register does indeed contain the expected
0xb105f00d value. However, if I run the following hacky code in U-Boot
to determine the FIFO depth, it comes out as 16, which explains the
symptoms I'm seeing:

void find_fifo_depth(void)
{
	volatile u8 *uart = 0x20201000;
	int depth = 0;

	/* Wait for TX FIFO empty */
	while (!(uart[0x18] & 0x80))
		;

	/* Disable UART */
	uart[0x30] &= ~1;

	/* Push chars into TX FIFO until full */
	for (;;) {
		uart[0] = 'A' + depth;
		depth++;
		/* Done if FIFO full */
		if (uart[0x18] & 0x20)
			break;
		if (depth > 64) {
			depth = -1;
			break;
		}
	}

	/* Re-enable UART */
	uart[0x30] |= 1;

	printf("FIFO depth: %d\n", depth);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/