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] [day] [month] [year] [list]
Date:	Fri, 25 Jun 2010 00:01:51 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit 
	system with 2GB+ RAM

Oops... put the old linuxppc list on the CC, sorry!

On Thu, Jun 24, 2010 at 23:45, Kyle Moffett <kyle@...fetthome.net> wrote:
> 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ