2011-02-28 03:13:05     u-boot spi flash problem since rev 2589 (trunk)

Document created by Aaronwu Employee on Sep 25, 2013
Version 1Show Document
  • View in full screen mode

2011-02-28 03:13:05     u-boot spi flash problem since rev 2589 (trunk)

Filip Van Rillaer (BELGIUM)

Message: 98463   

 

Hello,

 

Since rev 2589 (trunk) of u-boot, my system (bf537-stamp + custom SPI-add-on board) cannot boot anymore from spi-flash.  I think that there is a small mistake in rev 2589.  Please find below a patchfile to solve the problem in the file drivers/mtd/spi/spi_flash.c

 

Please also consider integrating in the trunk of u-boot the power-of-2 patch as found in http://blackfin.uclinux.org/gf/project/u-boot/tracker/?action=TrackerItemEdit&tracker_item_id=4771.  This patch is also included in the patch-file that I append.

 

Best regards,

Filip

 

patch2589

TranslateQuoteReplyEditDelete

 

 

2011-03-03 01:30:02     Re: u-boot spi flash problem since rev 2589 (trunk)

Mike Frysinger (UNITED STATES)

Message: 98618   

 

please dont combine unrelated fixes, and please dont use that patch format.  it is unreadable.  use the standard unified diff format instead.

 

what *exactly* did you need to change to make rev 2589 not break ?  just the changes to spi_flash_cmd_poll_bit in spi_flash.c ?

 

power-of-two mode should already work in trunk.  the patch in question was written before there were dedicated p2 funcs.  not that ive tested it personally as non of our boards have atmel flashes on them.

QuoteReplyEditDelete

 

 

2011-03-03 02:43:30     Re: u-boot spi flash problem since rev 2589 (trunk)

Filip Van Rillaer (BELGIUM)

Message: 98620   

 

Hello Mike,

 

Thank you for your answer.

 

Yes, just the small changes to poll_bit in spi_flash.c are needed  get u-boot running again for an at45db642d flashes.  By comparing rev 2589 with the version before, one can see this change in implementation too.

 

"use the standard unified diff format instead" : I attached a new patchfile.  Is this the expected format?

 

 

Concerning power-of -two mode: till recently I was using rev 2392 of u-boot (trunk). With that revision I had to patch the code to be able to force a new-flash to the new mode.  For the moment I also don't have any unused spi-flashes anymore to test an unpatched latest version of u-boot, but I am pretty sure that it is not able to un-lock new spi-flashes. From the atmel datasheet <<For the binary “power of 2” page size to become effective, the following steps must be followed: Program the one-time programmable configuration resister using opcode sequence 3DH, 2AH, 80H and A6H (please see Section 13.1). >>.  I grepped on the u-boot code, but I couldn't find anyting that looks like this sequence, so it is almost certain that the current u-boot cannot unlock a new spi-flash.  So please consider integrating the patch for the file mtd/spi/atmel.c.

 

Best regards,

 

Filip

 

patchfile

TranslateQuoteReplyEditDelete

 

 

2011-03-03 18:13:50     Re: u-boot spi flash problem since rev 2589 (trunk)

Mike Frysinger (UNITED STATES)

Message: 98637   

 

i guess the problem boils down to AT45 flashes providing a bit that says "i am ready" while everyone else provides a bit that says "i am busy".  so this change, while fixing AT45 flashes, will break all the other ones.  i guess what we actually want to do is leave the AT45 code alone and split out the AT25 code since the latter uses the same command set as everyone else.

 

as for converting from non-power-of-two mode to power-of-two mode, that cannot be done automatically by design.  this is why the examples/standalone/atmel_df_pow2.c program exists.  if you want to permanently modify your spi flash to power-of-two mode, then use that.

 

yes, that patch is in the correct format, thanks

QuoteReplyEditDelete

 

 

2011-03-04 02:59:39     Re: u-boot spi flash problem since rev 2589 (trunk)

Filip Van Rillaer (BELGIUM)

Message: 98641   

 

Hello Mike,

 

Thank you for your answers.

Concerning the AT45 flash: I have not inverstigated the spi-flash code itself, just the differences with the revision before for that AT45 flash. So your explanation makes sense.  For the moment I will keep on working with my patch, knowing that probably other flash-types will fail.  I  will upgrade my u-boot version from subversion when a nice solution that works again for all flashes is available.

 

Concerning the power-of-two mode: I like the solution of Brad Bozarth very much where it was integrated in u-boot and if-needed, converts the flash to the new mode and prompts for a reboot.  I will investigate if we keep using the patch of Brad or use the standalone program.

 

Best regards,

Filip

TranslateQuoteReplyEditDelete

 

 

2011-03-04 03:12:39     Re: u-boot spi flash problem since rev 2589 (trunk)

Mike Frysinger (UNITED STATES)

Message: 98642   

 

you can understand why that is never going to be merged.  u-boot cannot go reprogramming things on people unprompted.

 

if the read/write/erase of power-of-two flashes isnt working in trunk, i can take a look.

QuoteReplyEditDelete

 

 

2011-03-04 04:57:18     Re: u-boot spi flash problem since rev 2589 (trunk)

Filip Van Rillaer (BELGIUM)

Message: 98646   

 

Hello Mike,

 

On one hand I would say, indeed do not re-program things unprompted, but on the other hand, I would say, (correct me if I am wrong) blackfin cannot boot from a dataflash that is not in power-of-two mode, so the flash is useless until it is converted.  As a compromise one can either add a message asking the user to skip the operation [y/n] in the code.  Also the code to automatically switch the mode is between ifdef's, so also at compile-time the developer has full control over the expected behaviour via the config-file.  I leave it up to you, to choose the preferred behaviour.

 

I noticed your commit rev 2591.  I still have to test it, but I am expecting it to be OK, so that I can use it soon without patching the code.

Thanks, Filip

TranslateQuoteReplyEditDelete

 

 

2011-03-04 05:04:32     Re: u-boot spi flash problem since rev 2589 (trunk)

Mike Frysinger (UNITED STATES)

Message: 98647   

 

- u-boot is not blackfin specific

- you're assuming the spi flash is the boot source

- the simple act of probing a flash should not force a user prompt

- this is a one time operation for the life of the flash and should only ever come up once -- when the developer runs the example program

QuoteReplyEditDelete

 

 

2011-03-04 05:30:37     Re: u-boot spi flash problem since rev 2589 (trunk)

Filip Van Rillaer (BELGIUM)

Message: 98650   

 

Hello Mike,

 

I accept your comments,

Thanks, Filip

TranslateQuoteReplyEditDelete

 

 

2011-03-04 16:28:05     Re: u-boot spi flash problem since rev 2589 (trunk)

Mike Frysinger (UNITED STATES)

Message: 98658   

 

if you really prefer this behavior, you could add it to your own board's file in misc_init_r().  then you wouldnt need to patch the spi driver at all.

 

just to be clear ... are any changes necessary to read the AT45 in power-of-two mode ?  or are you just using this patch for the auto-reprogram feature ?  in other words, is there an open bug here in the AT45 spi flash driver i need to be looking into ?

QuoteReplyEditDelete

 

 

2011-03-14 05:13:56     Re: u-boot spi flash problem since rev 2589 (trunk)

Filip Van Rillaer (BELGIUM)

Message: 98917   

 

Hello Mike,

 

Sorry for my late reaction, but I was not in the office last week.  What the current u-boot implementation is not able to handle is to change the mode of the at45 to the power-of-two mode so that a Blackfin can boot from it.  The patch of Brad Bozarth makes this possbile: i.e. load u-boot with an emulator in memory and u-boot will, if needed, change the spi-flash to the correct mode and ask for reboot.  Without the patch one has to use (as you suggested) the examples/standalone/atmel_df_power2.c program.  There are no changes needed to read the AT45 once it is in the power-of-two mode, so no open bug.  Indeed the patch is used to auto-reprogram the power-of-two mode.

 

BR,

Filip

Attachments

Outcomes