topic Re: Anyone used the 'sf' command in more recent versions of u-boot? in i.MX Processors

Anyone used the 'sf' command in more recent versions of u-boot?

EdSutter — Wed, 23 Oct 2013 11:48:54 GMT

I used the sf command in the u-boot that comes with LTIB, but have since updated to u-boot-2013.10.

The code is quite different, and now the 'sf' command and the ability to configure SPI-flash as the

environment space doesn't work for me.

Before I start digging too deep, it would be nice to know if anyone else has used the "sf" command

(or set up SPI-flash as the environment storage area) on SABRESD for a recent u-boot version.

Thanks in advance.

Re: Anyone used the 'sf' command in more recent versions of u-boot?

AnsonHuang — Mon, 28 Oct 2013 08:40:22 GMT

Hi, Ed Sutter

I ever used u-boot imx_v2013.04, the 'sf' command was working just fine, but the setup of SPI-flash as environment was broken due to wrong setting of sector size, now we already had a patch to fix it in our internal tree, 3328e2b9d8a74f7348a959650cfbad4e63b8eed6. Not sure whether you can see this patch from external git, but 'sf' command did work.

Re: Anyone used the 'sf' command in more recent versions of u-boot?

EdSutter — Tue, 29 Oct 2013 14:52:25 GMT

Ok, I'll back off to u-boot-2013.04 and see if I have similar results.

Will post results shortly. Thanks much,

Re: Anyone used the 'sf' command in more recent versions of u-boot?

EdSutter — Wed, 30 Oct 2013 14:36:58 GMT

Tried the same with u-boot-2013.04 (from denx ftp).

I'm seeing the same issue. The probe fails because the ID always reads back as 0xff.

I've verified that pins are configured properly, and I see on the scope that 0x9F (CMD_READ_ID_)

is written, but there's no response unless I change the code so that the function spi_xchg_single()

only accesses the SPI data fifo with a bitcount of 32.

Did you have to modify any of the underlying SPI controller code (beyond just changing the sector size)?

Also, I assume when you refer to "imx_v2013.04" you're talking about the u-boot-2013.04 from denx ftp site right?

Re: Anyone used the 'sf' command in more recent versions of u-boot?

fabio_estevam — Wed, 30 Oct 2013 16:49:20 GMT

Hi Ed,

I have just tested 2013.10 on a mx6qsabrelite board:

U-Boot > sf probe

SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB

mx6qsabresd does not have the SPI NOR flash support on 2013.10.

It should be simple to add it though.

Please share the patch you are using in order to add SPI support for mx6qsabresd at the U-boot list so that we can help you from there.

Regards,

Fabio Estevam

Re: Anyone used the 'sf' command in more recent versions of u-boot?

EdSutter — Wed, 30 Oct 2013 17:08:39 GMT

Fabio,

Thanks for responding. This is kicking my butt...

I've written the driver code for this interface in my own boot monitor

and I also had it working in the LTIB-uboot distribution (quite old); so

I think

I understand the interface. This tells me that my hardware is correct.

I recently updated kernel and uboot, and now uboot doesn't work with

the same SPI flash device and I see that the underlying SPI interface

code has

changed (since 2009 version) significantly. I'm using an ATMEL part,

but the

error occurs before and device specific code is even used (the

CMD_ID_READ in

the probe fails).

I have the control lines on a scope and I see the 9F (CMD_ID_READ)

issued to the

device with CS low; however, the only way I can get it to respond with

something other

than FF's is if I seriosly hack the spi_xchg_single() function. With

this hack, I can see

the device send back the ID. This at least tells me that I have the

IOMUX stuff set up

right (plus, as I said, I got this working in the 2009 version of uboot).

Anyway, could you do me a big favor and build your u-boot with...

#define debug printf

put at the top of ...

drivers/spi/mxc_spi.c

and then run your sf probe command and send me that output?

That may help me see where my problem lies?

BTW... I'm emailing because for some reason I can't get to the community

website right now.

Freescale Community <https://community.freescale.com/>
<https://community.freescale.com/>

Anyone used the 'sf' command in more recent versions of u-boot?
reply from Fabio Estevam
<https://community.freescale.com/people/FabioEstevam?et=watches.email.thread>
in /i.MX Community/ - View the full discussion
<https://community.freescale.com/message/359521?et=watches.email.thread#359521>

Re: Anyone used the 'sf' command in more recent versions of u-boot?

EdSutter — Wed, 30 Oct 2013 17:41:03 GMT

Fabio,

One other quick question...

I'm running with the raw u-boot-2013.10 from

http://ftp.denx.de/pub/u-boot/u-boot-2013.10.tar.bz2

Are there any patches that need to be applied to that?

Freescale Community <https://community.freescale.com/>
<https://community.freescale.com/>

Anyone used the 'sf' command in more recent versions of u-boot?
reply from Fabio Estevam
<https://community.freescale.com/people/FabioEstevam?et=watches.email.thread>
in /i.MX Community/ - View the full discussion
<https://community.freescale.com/message/359521?et=watches.email.thread#359521>

Re: Anyone used the 'sf' command in more recent versions of u-boot?

OtavioSalvador — Wed, 30 Oct 2013 19:18:39 GMT

From Fabio's comment (and code inspection) it seems the support has not been send to U-Boot mainline yet. It is easy to port from U-Boot i.MX 2013.04 to mainline.

The first patch adding support for it, in Freescale tree, was:

uboot-imx.git - Freescale i.MX u-boot Tree

You can port it to U-Boot 2013.10 and send the patch to U-Boot mailing list.

Re: Anyone used the 'sf' command in more recent versions of u-boot?

EdSutter — Wed, 30 Oct 2013 20:59:21 GMT

Fabio/Otavio,

Thanks for the responses. I apologize for some of the poorly formatted replies above. For some reason I was unable to access this site via HTTP, so I replied to the email directly.

Anyway, things are back now, and I think I finally understand the issue. Otavio, note that I had tried running with the u-boot-2013.04 and found that I had the same issues as with the mainline.

The following comments are based on using the u-boot-2013.04 tar ball...

After looking and digging for a few days, I believe I understand why it was not working for me...

LONG STORY (skip to SHORT STORY if not interested):

I had this working in Micromonitor and the uboot-2009.08, so I knew the hardware was good. The update to u-boot-2013.04 is where it broke for me.

After studying the new SPI control code (uboot-2013.04 is significantly different than uboot-2009.08 from LTIB), I believe the problem is that the new code only works if the SPI chip select is driven by GPIO. If the chip select is driven by the ECSPI controller directly, then things break (IMHO). This is what I was doing, and I have now changed over to running the SPI-CS line with GPIO and things are working. So, I can't absolutely confirm this to be true, but as far as I can tell, the SPI code in uboot for iMX6/ECSPI controller does not work when ECSPI controls CS for devices that require the CS to remain low for the entire READ_DEVICE_ID protocol (write-command, read-id block). The toggling of CS for this transaction did not allow me to retrieve the AT25DF321 device ID.

SHORT STORY:

I was trying to use the ECSPI-controlled chip select to my SPI flash. I changed the code so that the chip select line is controlled through GPIO and things now work.

Its possible that I just had something wrong in my pin configuration when I was running in ECSPI-controlled CS; so if someone else has successfully used this interface in that mode with this code I'd like to know that.

Thanks for the suggestions, I think this is finally resolved for me,

Re: Anyone used the 'sf' command in more recent versions of u-boot?

fabio_estevam — Fri, 08 Nov 2013 18:36:10 GMT

Hi Ed,

Just sent a patch adsing SPI NOR flash support for mx6sabresd:

http://marc.info/?l=u-boot&m=138393491401050&w=2

Regards,

Fabio Estevam

Re: Anyone used the 'sf' command in more recent versions of u-boot?

EdSutter — Fri, 08 Nov 2013 19:11:39 GMT

Fabio,

Great! This is essentially the same thing I did in my local copy; but in my case I had to use a device that would connect to ECSPI5 so that I could use is as the boot device (U14 cannot boot the iMX6 as is). I didn't submit the patch because the wiring we did required that the ACCL_INT_IN pin of the accelerometer be lifted to avoid outputs conflicting.

Thanks,

Re: Anyone used the 'sf' command in more recent versions of u-boot?

EdSutter — Fri, 08 Nov 2013 19:13:55 GMT

Fabio,

Note also, that I still think the u-boot code does not properly support the ability to use the ECSPI controller to activate the chip select. That's ok, but still worth noting because I wasted a few days because of that (I was trying to use the CS as controlled through ECSPI instead of GPIO).

Re: Anyone used the 'sf' command in more recent versions of u-boot?

artyeffem — Mon, 10 Feb 2014 20:48:12 GMT

I'm also not getting an active chip select on eCSPI3 for an i.MX6Solo-based board, stalling the initial transfer. Is this GPIO technique a workaround for an errata? That is, I'd prefer to use the controller for CS, but sounds like this was not working for the OP

Re: Anyone used the 'sf' command in more recent versions of u-boot?

EdSutter — Mon, 10 Feb 2014 21:07:36 GMT

No, I don't think this is any chip-errata workaround. I had been using ECSPI to control the chip select in Micromonitor and it worked just fine. As far as I can tell, this is just the way it is implemented in u-boot. I may have something configured incorrectly that causes this but I don't think so. Observing the code, it appears to really only work if the CS pin is GPIO-driven instead of ECSPI-driven.