Update fatfs to R0.13c

[ThomasHornschuh]

This PR contains mainly the update of fatfs to R0.13c. In addition a few more configuration options for the mmc component in the board description have been added. See file src/fatfs/FATFS_README.md for details.
I have tested the coding on my FPGA based RISC-V SoC only, so I cannot say if it works well on any other platform.

Sizes (on RISC-V) with the following configuration. ARM code sizes are likely smaller.

 mmcfs= { spi=0, codepage=850, 
             use_utf8_api=false, tiny=true, use_locking=true,
             files=4, lfn_length=255
 }

mmcfs module:

text	   data	    bss	    dec	    hex	filename
   2274	      0	    748	   3022	    bce	src__mmcfs.o

ff module:

   text	   data	    bss	    dec	    hex	filename
  17698	      0	    132	  17830	   45a6	src__fatfs__ff.o

ffunicode module

text	   data	    bss	    dec	    hex	filename
   1506	      0	      0	   1506	    5e2	src__fatfs__ffunicode.o

[ramangopalan]

@ThomasHornschuh, @bogdanm, I have looked at this PR for a while. Can
I help merge these changes? I have a few boards with me and some free
time. I can help with some testing. OR is someone already working on
testing this? Please let me know.

[bogdanm]

@ramangopalan By all means, yes. What kept me from merging this is that I'm currently unable to test the changes on my side. Even the CI seems broken and I haven't had the time to look into it. So please, if you can look into it, that'd be great.

[ThomasHornschuh]

@ramangopalan: If you have questions, please ask. Looking foward in having my PR merged.

[ramangopalan]

@bogdanm, perfect! I will start this tomorrow. @ThomasHornschuh, sure. Thanks! R

[ramangopalan]

@ThomasHornschuh, thanks for the patch. I have had a look at your
changes. The following configuration works just fine on my STM32 kit
with my 4GB Transcend SD card.

mmcfs = { spi = 0, cs_port = 0, cs_pin = 4, codepage = 437, tiny = true, use_locking = true, files = 4 },

I like the way the ffconf parameters are now generated as MMCFS_
macros in the board configuration file. Perfect! I will test it over
the next 2 - 3 days with a lot of SD card I/O and write back with
results. But before, a quick one: is there a reason why you wouldn't
force f_mount in mmcfs.c?

  if ( f_mount( mmc_fs, "0:", 0 ) != FR_OK )
    return DM_ERR_INIT;

Assuming a physical error, it might be easier to halt after f_mount and
check for its return rather than going further through shell_start.

[ThomasHornschuh]

@ramangopalan:
Great that it works. Regarding f_mount: There is no specific reason. I tried both variants, it makes not really a difference, because eLua will look for startup files soon anyway. So I have no clear preference yet. Please note that I have not tested multiple SD cards yet.
Maybe you have the possibility to test this

[ramangopalan]

I ran some tests on a 32GB Samsung EVO Plus. Works fine on an Infineon XMC400-E144x at a lower SPI bus speed of 8MHz. Certainly not with its default of 10MHz. I don't suspect the stack. Just the SPI and clocking. More thoughts in a day OR two. Long days.

I want to be able to run Jaunty Ubuntu (for PXA-255) within Dimitry Grinberg's uARM with your changes on XMC4500-E144x1024. That will be a fun test. I have the test rig ready.

[ThomasHornschuh]

I think also that this is hardware (SPI) related. I didn’t changed the driver code. On my FPGA based design on a Digilent Arty board it works successfully with 20.83 Mhz on an older 2GB card from Hama and a Kingston 16GB card. Does your hardware has a pull-up resistor on the data lines?

[ramangopalan]

Sorry about the brief pause. I will have some time for some more results this weekend.

[ramangopalan]

@ThomasHornschuh, so sorry about the long delay. Today, I ran some
tests with my 4GB Transcend micro SD card and the Infineon
XMC400-E144x. I was able to reproduce my work on uARM from many years
ago. I once more saw PXA-255 GNU/Linux boot (super slowly) on my
boot-kit.

I checked your abstraction code in mmcfs.c as well. It works fine so
far. I did this experiment within the context of Infineon's DAVE IDE
which uses FATFS R0.13a (and not 0.13c). I will try to upgrade the
generated FATFS code to 0.13c and see the outcome tomorrow. Oh snap!
FATFS R0.14 is already out!

[ThomasHornschuh]

generated FATFS code to 0.13c and see the outcome tomorrow. Oh snap!
FATFS R0.14 is already out!

@ramangopalan
Hi, nice to hear that you made progress. Maybe we can take a look into 0.14, hopefully upgrading will not be hard.