linux-kernel - of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM

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-next>] [day] [month] [year] [list]

Date:	Thu, 24 Jun 2010 23:45:11 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	linuxppc-embedded@...ts.linuxppc.org, linux-kernel@...r.kernel.org
Subject: of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system 
	with 2GB+ RAM

Hello,

I've got a new P2020 (32bit mpc85xx family) board I'm working on a
port for that includes 2 NOR flashes (128MB each) and a removable
SO-RDIMM of 2GB or 4GB.  Unfortunately when I configure both flashes
in the device-tree off my elbc, Linux is completely unable to access
the second one because it attempts to ioremap() the entire virtual
address space of both FLASH chips.

Even with only one flash chip enabled, there's a bit of a noticeable
performance degradation because the mapping consumes almost all of my
available vmalloc space and forces bounce-buffering for all my
HIGHMEM.

It looks like the "of-flash" driver currently requires that the whole
chip be mapped in the kernel at once.  I would much rather have a 50%
performance penalty on flash accesses (which are already very slow)
and regain most of the vmap space.

So the question is, is there a way to convince the MTD layer to
iomap() only what it needs to access to do reads and writes?  If not,
what changes would need to be made to MTD and/or "of-flash" to create
such functionality?

Cheers,
Kyle Moffett
--
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/