From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Sat, 28 Aug 2010 18:26:50 -0400 Subject: [U-Boot] [PATCH] MTD/SPI/FLASH: add support for Ramtron FRAMs using SPI In-Reply-To: <4C798A8F.2040402@emk-elektronik.de> References: <1282740439-7910-1-git-send-email-u-boot@emk-elektronik.de> <201008281748.40158.vapier@gentoo.org> <4C798A8F.2040402@emk-elektronik.de> Message-ID: <201008281826.51296.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Saturday, August 28, 2010 18:15:43 Reinhard Meyer wrote: > Dear Mike Frysinger, > > On Thursday, August 26, 2010 16:00:50 Reinhard Meyer wrote: > > interesting, but what if we push it further. something like this > > (untested): > > That code does not address the following issues to complete extend: > > 1. JEDEC conformant that have ID in first byte > 2. JEDEC conformant that have ID in later byte why doesnt it ? look at the structure i created a bit closer as well as the code that parses it. > The question that remains is if any ID can be assigned twice in different > positions and them meaning different manufacturers? > > 7f 7f 7f 7f 7f 7f c2 = ramtron { 6, 0xc2, ramtron_probe, }, > 7f 7f 7f c2 = some other manufacturer? { 3, 0xc2, some_other_manu_probe, }, > 3. non JEDEC conformant or those that do not honor the read-id command > and thus present 0xff _if_ the MISO line is pulled up that isnt really changed at all by my patch. there is a simple idcode[0] == 0xff branch for people to call probe functions which are prepared to handle non-jedec compatible probes. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20100828/aba6ebe5/attachment.pgp