On 12/17/2018 10:42 AM, masonccyang@xxxxxxxxxxx wrote:
>> > +static int rpc_spi_io_xfer(struct rpc_spi *rpc,
>> > + const void *tx_buf, void *rx_buf)
>> > +{
>> > + u32 smenr, smcr, data, pos = 0;
>> > + int ret = 0;
>> > +
>> > + regmap_write(rpc->regmap, RPC_CMNCR, RPC_CMNCR_MD | RPC_CMNCR_SFDE |
>> > + RPC_CMNCR_MOIIO_HIZ | RPC_CMNCR_IOFV_HIZ |
>> > + RPC_CMNCR_BSZ(0));
>> > + regmap_write(rpc->regmap, RPC_SMDRENR, 0x0);
>> > + regmap_write(rpc->regmap, RPC_SMCMR, rpc->cmd);
>> > + regmap_write(rpc->regmap, RPC_SMDMCR, rpc->dummy);
>> > + regmap_write(rpc->regmap, RPC_SMADR, rpc->addr);
>> > +
>> > + if (tx_buf) {
>> > + smenr = rpc->smenr;
>> > +
>> > + while (pos < rpc->xferlen) {
>> > + u32 nbytes = rpc->xferlen - pos;
>> > +
>> > + regmap_write(rpc->regmap, RPC_SMWDR0,
>> > + get_unaligned((u32 *)(tx_buf + pos)));
>> > +
>> > + if (nbytes > 4) {
>> > + nbytes = 4;
>> > + smcr = rpc->smcr |
>> > + RPC_SMCR_SPIE | RPC_SMCR_SSLKP;
>> > + } else {
>> > + smcr = rpc->smcr | RPC_SMCR_SPIE;
>> > + }
>> > +
>> > + regmap_write(rpc->regmap, RPC_SMENR, smenr);
>> > + regmap_write(rpc->regmap, RPC_SMCR, smcr);
>> > + ret = wait_msg_xfer_end(rpc);
>> > + if (ret)
>> > + goto out;
>> > +
>> > + pos += nbytes;
>> > + smenr = rpc->smenr & ~RPC_SMENR_CDE &
>> > + ~RPC_SMENR_ADE(0xf);
>> > + }
>> > + } else if (rx_buf) {
>> > + while (pos < rpc->xferlen) {
>> > + u32 nbytes = rpc->xferlen - pos;
>> > +
>> > + if (nbytes > 4)
>> > + nbytes = 4;
>> > +
>> > + regmap_write(rpc->regmap, RPC_SMENR, rpc->smenr);
>> > + regmap_write(rpc->regmap, RPC_SMCR,
>> > + rpc->smcr | RPC_SMCR_SPIE);
>>
>> Hm... our flash chip (Spansion S25FS512S) doesn't get detected; it sends
>> JEDEC ID bytes 0..3 repeatedly, unless I copy the SSLKP logic from the writing
>> branch above...
[...]
> what follows is my booting log, FYI.
> ------------------------------------------------------------------
> [ 1.625053] m25p80 spi5.0: s25fl129p1 (16384 Kbytes)
Looking at the spi_nor_ids[], this chip has 0x01 in both byte 0 and byte 4...
> [ 1.634391] 12 fixed-partitions partitions found on MTD device spi5.0
> [ 1.642198] Creating 12 MTD partitions on "spi5.0":
> [ 1.647598] 0x000000000000-0x000000040000 : "Bank 1 - Boot parameter"
> [ 1.660893] 0x000000040000-0x000000180000 : "Bank 1 - Loader-BL2"
> [ 1.671287] 0x000000180000-0x0000001c0000 : "Bank 1 - Certification"
> -----------------------------------------------------------------------
>
>>
>> > + ret = wait_msg_xfer_end(rpc);
>> > + if (ret)
>> > + goto out;
>> > +
>> > + regmap_read(rpc->regmap, RPC_SMRDR0, &data);
>> > + memcpy_fromio(rx_buf + pos, (void *)&data, nbytes);
>> > + pos += nbytes;
>>
>> ... and it skips byte 4 unless I copy the code from the end of the writing
>> branch, clearing CDE/ADE. But even then the byte 4 reads as 0x03 instead of 0.
>
> yup, I think this is some kind of RPC HW limitation,
> in RPC manual I/O mode, it only could read 4 bytes data w/ one command.
>
> That is, one command + read 4 bytes data + read 4 bytes data + read 4 bytes data + ...
> will get the incorrect data.
>
> That's why RPC in manual I/O mode, driver only could do,
> one command + read 4 bytes data; one command + read 4 bytes data and so on.
Yes. But the problem is you can't work around by reading 4 bytes at most
for the RDID command -- it has no address phase. Every time you "restart"
reading, you get bytes 0..3 again, like me. It seems that this approach works
for you only by chance...
> thanks & best regards,
> Mason
MBR, Sergei
