mcf5441x, esdhc dma read

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

mcf5441x, esdhc dma read

1,175 Views
angelo_d
Senior Contributor I

Hi all,

i am trying to use an u.boot driver, fsl-esdhc, to access sd cards.

The driver, in the default mode, uses DMA read. There is available another mode called "PIO" that seems btw not well working nor much performant.

The driver works fine, but when i read data using DMA, btw, i read all 32bit words (4 bytes groups) swapped. Likely, for the fact mcf5441x is big endian.

Looking in the hw registers if a dma-endiannes swapped read option is available, seems there is nothing.

So if i understand, with this cpu, at least using DMA, i cannot read any SD written from other system. Am i correct ?

Any idea of what i could do ?

Thanks,

Angelo Dureghello

0 Kudos
Reply
5 Replies

882 Views
angelo_d
Senior Contributor I

Hi Fang, thanks, good to know about those issues.

Hi Tom,

many thanks ! I checked linux drivers, MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER seems not covering my case, but i remembered of PPC, so checked mxcmmc.c driver, and found functions for PPC only that swaps the read buffers :smileyhappy:

Freescale provided u-boot seems only accessing nand, loading kernel from TFTP and at least in u.boot mainline afaik there was no support for coldfire uSDHC.

For now, the byte "swap" solution after DMA read seems to work properly, and the driver works fine.

I have a last issue to manage, btw:

RM says in more points that the SDHC clock must not exceed 25Mhz (and shouldn't support > 25Mhz), but the HOSTCAPBLT register says HS is supported, so u-boot driver switches to 50Mhz, that seems freezing the board. In 25Mhz (legacy) mode, all works fine.

Any idea about ? For now i am going to disable HS from hostcaps for mcf5441x case.

Regards,

Angelo

0 Kudos
Reply

882 Views
TomE
Specialist II

You were working on this in January!

https://community.nxp.com/thread/469066

> RM says in more points that the SDHC clock must not exceed 25Mhz

I can only find that in one place. Do you have other places you can reference? It says in more places it can run at 40 or 50.

8.1.2 Features

- eSDHC clock (40 MHz max)

Table 8-4. PLL_DR Field Descriptions

Max 250 MHz

25.1.2 Features

SD bus clock frequency over 25 MHz

Up to 160 Mbps data transfer ((Matches 40MHz spec above))

Full-speed mode (greater than 25 MHz)

Table 25-13. SYSCTL Field Descriptions (continued)

The maximum SD clock frequency is 25 MHz, and should never exceed this limit.

Table 25-22. HOSTCAPBLT Field Descriptions

High speed support. Indicates if the eSDHC supports high speed mode (50MHz and the register says 50MHz)

When you can't believe the Reference Manual (put together from sections) you can usually trust the Data Sheet. it says:

4.15.1 eSDHC timing specifications

Low Speed: 400 kHz

SD/SDIO Full Speed: 40 MHz

MMC Full Speed: 20 MHz

Identification Mode: 400 kHz

(2) In normal data transfer mode for SD/SDIO card, clock frequency can be any value from 0 to 25 MHz.

Confusing isn't it? This is the brand new Revision 5 of the manual "with all the known bugs fixed". You've found some new bugs.

What I would read from that is that the eSDHC MODULE that has been put in this chip is designed to run at 50MHz, and it's "HSS" bit is set to say that it can. BUT, the system that it has been put in can't support that speed for clocking, pin or data transfer reasons. Maybe that same module can run at 50MHz in an i.MX or PPC product.

The only real "reference" for these things is the Evaluation Board and the software released to run on that.

There should be something deep in the Linux version that was released to work with that chip. This information isn't in the current Linux Tree, as it looks like these chips were never supported in the "mainline", but only with versions of Linux with a package of Freescale patches applied. These releases don't appear to be available any more, so if you didn't grab a copy back in 2010 (when Rev 3 of the Reference Manual was printed) it'll be difficult finding a copy. Maybe someone reading this post can send you an old copy.

Tom

0 Kudos
Reply

882 Views
angelo_d
Senior Contributor I

Hi Tom,

still many thanks for the kind reply.

Yes, i was on this from some months, mainly becouse i work on opensource things in private time, often in the night :smileyhappy:

I solved all with this patch: [U-Boot,v2] drivers: esdhc: add support for ColdFire mcf5441x family - Patchwork 

Mainly, trying to go at 50Mhz, i get the system frozen.

At 25Mhz 4 bits, all works fine. For now i stay this way, kernel boots fine and this is what i need.

(PS: In the meantime, also DMA driver i set up for this chip has been accepted into Linux).

Best regards,

Angelo

0 Kudos
Reply

882 Views
miduo
NXP Employee
NXP Employee

Hi,

Well, would you aware that we had several errata for MCF5441X esdhc. See detail below:

https://www.nxp.com/docs/en/errata/MCF54418DE.pdf 

Pay more attention on errata SECF217.

0 Kudos
Reply

883 Views
TomE
Specialist II

There are nine issues in that document concerning the ESDHC. There's quite a lot concerning the LENGTHS of data to transfer, requiring extra bytes on reads and writes to get "more than four". There's nothing related to the poster's question, which is on the byte ORDER.

> i cannot read any SD written from other system. Am i correct ?

Unlikely. Have you searched this forum to see if anyone else has posted on this topic?

This CPU has a BYTEREV instruction. So you can always swap the data in the buffers before writes and after reads if required. SDHC is complicated. There are controller commands, card commands and data to worry about.

SD cards are usually written with DOS FAT file systems. The "endianness" of these is defined. These have to be read by standard software, and UBOOT should be getting this right, somehow. Also, there are Linux drivers that work. Have you looked at them? Read the following and see if it matches, or if it gives any clues:

((EDIT)) Something has gone wrong with NXP's forum software. The following link didn't work when I clicked on it because there's some failed "you are leaving NXP" redirection stuff on the start of it. Hover over it and see what the link really is. To visit this site you may have to manually copy-and-paste the display text.

https://elixir.bootlin.com/linux/v4.18.4/source/drivers/mmc/host/Kconfig

((EDIT)) Maybe I have to use the "Inset Link" button to get a working link. Let's try that and see what happens... No, that's the same, but it worked the next time I clicked on it. It works if you click, but NOT if you ask for "Open in new window" under Firefox. That gives "jive, Oops, the page can't be found".

https://elixir.bootlin.com/linux/v4.18.4/source/drivers/mmc/host/Kconfig

config MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
     bool
     depends on MMC_SDHCI
     select MMC_SDHCI_IO_ACCESSORS
     help
       This option is selected by drivers running on big endian hosts
       and performing I/O to a SDHCI controller through a bus that
       implements a hardware byte swapper using a 32-bit datum.
       This endian mapping mode is called "data invariance" and
       has the effect of scrambling the addresses and formats of data
       accessed in sizes other than the datum size.

       This is the case for the Nintendo Wii SDHCI.‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Interestingly, up to 4.2 of the above file, the last line said:

https://elixir.bootlin.com/linux/v4.2/source/drivers/mmc/host/Kconfig

      This is the case for the Freescale eSDHC and Nintendo Wii SDHCI.‍

I think that means that support for Freescale was removed between 4.2 and 4.18 (it isn't in 4.4 either).

The above reference probably doesn't match what you're trying to do, but shows that any endian problems are addressed in there somewhere, and reading those solutions might help you. The hardware drivers are in the same directory as the above file, so you can look at those. You may need to

The best starting point would be a Freescale SDK booting Linux from an SD card. That should show you exactly how it is done, both in the U-Boot code and in the Linux Drivers that then run. You would best get the patched version of Linux that Freescale released for this purpose. Searching finds this as a starting point:

((EDIT)) The following link has the same "you are leaving NXP" redirection on it which may or may not work for you.

https://www.nxp.com/docs/en/application-note/AN4426.pdf

Tom

0 Kudos
Reply