Hi, On 03/06/2014 05:42 PM, Sören Brinkmann wrote: > On Thu, 2014-03-06 at 02:31PM +0100, Mike Looijmans wrote: >> On 03/04/2014 10:00 PM, Sören Brinkmann wrote: >>> On Tue, 2014-03-04 at 10:06PM +0200, Eli Billauer wrote: >>>> Hello Sören, >>>> >>>> wp-inverted solves the practical problem indeed, and fools the >>>> driver into thinking that the card has an inverted write protection >>>> sensor, and the logic zero that it finds in the hardware register >>>> means that the card isn't write protected. >>>> >>>> I'm insisting on this patch, because I think that the device tree >>>> should describe the hardware as it is, and not fool the driver into >>>> behaving the way we want it to. These tricks always bite back later >>>> on. >>> Well, why is broken-wp more accurate than wp-inverted? Strictly >>> speaking the WP is there and working, it's just tied off to some value >>> you want to have interpreted the other way. >>> Anyway, seems like this is solvable with wp-inverted and whether the >>> additional quirk is needed I leave to others do decide. >> >> I've begged for this patch - or a similar one - to be included too, >> because on our boards, the "wp" value appears to be sort of random. >> Out of 5 prototype boards, 3 would only boot with wp-inverted while >> the other 2 wouldn't boot with wp-inverted set. >> >> In our case I really don't know (and I don't care either) to which >> logic level the wp happens to think it's wired. I just want to be >> able to tell the driver that the WP line is >> free-floating-and-might-have-any-random-value-at-any-given-moment >> which is a bit long, so I'd go for disable-wp instead. > > Could you provide the design you use and give more details? According to > the people I talked to, the signal should never float, unless you pin it > out and don't drive it. > Actually, you should open a support case for this. It is not supposed to > happen. we have got this from Mike (we couldn't reply because he has lost this email thread. Mike: "I think I found the issue. In ps7_init.c as generated by the tools, it sets the "WP" pin not to EMIO, but to MIO 0. We use pin 0 for a status LED. # devmem 0XF8000830 0x002E0000 Register 0XF8000830 is SD0_WP_CD_SEL, and 0x002E0000 sets CD to pin 46 and WP to pin "0", not to EMIO as I specified in the design. " Eli: Maybe you have the same issue as Mike. Can you please check it? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
Attachment:
signature.asc
Description: OpenPGP digital signature
