SD Card, FAT32, SD Card hot plug with uClinux on LPC1788

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

SD Card, FAT32, SD Card hot plug with uClinux on LPC1788

1,045 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Vladimir Khusainov on Tue Feb 14 02:24:28 MST 2012
Here is a sample session showing how to use SD Card with the LPC1788 running Emcraft Systems' port of uClinux.

Highlights of this demo are as follows:

- A FAT32 filesystem is mounted on the SD Card allowing to easily move data between the LPC1788 target and a Windows PC.
- "Hot-plug" is supported, that is, it is possible to insert and remove an SD Card on a running system.
- The SD Card driver makes use of a DMA driver achieving a decent 4 MBytes/sec rate on files in a FAT32 filesystem.

The initial set-up is an Embedded Artists' LPC1788 development board with an SD Card with a FAT32 filesystem inserted into the SD Card slot.

Boot the Linux kernel and see the kernel log messages:

<code>
[...]
mmci-pl18x dev:mmc0: DMA buffer: phy:a0d20000, virt:a0d20000
mmci-pl18x dev:mmc0: mmc0: MMCI rev 0 cfg 00 at 0x00000000400c0000 irq 29,-1
[...]
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SDHC card at address b368
mmcblk0: mmc0:b368 SD 3.84 GiB
mmcblk0: p1
[...]
</code>

Mount the FAT32 file system on the first partion of the SD Card:

<code>
~ # mount /dev/mmcblk0p1 /mnt/
~ # cat /proc/mounts
rootfs / rootfs rw 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0 /dev/mmcblk0p1 /mnt vfat rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
</code>

Measure the data transfer rate from the SD card by reading a large file from the FAT32 file system:

<code>
~ # cd /mnt/Music/
/mnt/Music # date ; cat FinamFM-VelvetUG.mp3 > /dev/null ; date ; ls -l FinamFM-VelvetUG.mp3
Thu Jan 1 00:00:15 UTC 1970
Thu Jan 1 00:00:28 UTC 1970
-rwxr-xr-x 1 root root 52060058 Oct 31 2011 FinamFM-VelvetUG.mp3
</code>

Copy an executable to the FAT32 and them run it from there:

<code>
~ # cp /bin/busybox /mnt/
~ # /mnt/busybox echo hello1
hello1
</code>

Not, let's test the hot-plug functionality. Bring the target down and remove the SD Card from the slot. Boot the kernel and see the kernel messages.

<code>
[...]
mmci-pl18x dev:mmc0: DMA buffer: phy:a0d20000, virt:a0d20000
mmci-pl18x dev:mmc0: mmc0: MMCI rev 0 cfg 00 at 0x00000000400c0000 irq 29,-1
[...]
</code>

Let's check the list of block devices currently present in the system. No mmcblk0[...] devices are present since there is no SD card inserted into the slot.

<code>
~ # ls -l /sys/block/
~ #
</code>

Insert an SD card with a FAT32 file system into the slot and wait for the Linux kernel to detect it:

<code>
~ # mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SDHC card at address b368
mmcblk0: mmc0:b368 SD 3.84 GiB
mmcblk0: p1
</code>

See the list of block devices currently present in the system:

<code>
~ # ls -l /sys/block/
lrwxrwxrwx 1 root root 0 Jan 1 00:04 mmcblk0 -> ../devices/dev:mmc0/mmc_host/mmc0/mmc0:b368/block/mmcblk0
~ #
</code>

Mount the FAT32 file system on the SD Card:

<code>
~ # mount /dev/mmcblk0p1 /mnt/
~ # /mnt/busybox echo hello2
hello2
</code>

Unmount the file system:

<code>
~ # umount /dev/mmcblk0p1
~ #
</code>

Remove the SD card from the slot. The kernel will detect the card removal:

<code>
~ # mmc0: card b368 removed
</code>
Labels (1)
0 Kudos
4 Replies

705 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Vladimir Khusainov on Mon Mar 05 09:56:27 MST 2012
Hi Mike,

We sent you some patches over email that should help you with SD Card, SysTick and NAND Flash.

I think it would be great if you could post some of your examples here. Not sure if this thread is the right place, it being about SD Card specifically. I believe there is a thread dedicated to review of Emcraft's uClinux port in this forum. Perhaps, those examples should go there.

Regards,
Vladimir
0 Kudos

705 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mcruse on Sun Mar 04 16:00:06 MST 2012
Hi Vladimir,

your comments did help, thanks.

After digging around in the kernel a bit more I did realize that there was more to getting SD/MMC going than just kernel configuration.

I sent an email to both emcraft support email addresses regarding SD/MMC.

I'll keep working on getting SysTick support going for the 1788 but if you have any comments on how to make sure that the SysTick exception
calls the asm_do_IRQ() function with the right context I would welcome them.

I completely understand the priorities here and indeed using "normal" timers was the most expedient path.

I think uClinux is going to work quite well for my project. Performance is quite reasonable. and I have easily been able to write basic
loadable kernel modules to handle GPIO interrupts etc.

Just need to figure out the 16MB limit versus loadable modules thing...

I might post some examples here soon if people are interested.

Regards,

Mike Cruse
0 Kudos

705 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Vladimir Khusainov on Fri Mar 02 04:16:19 MST 2012
Hi Mike,

o) Regarding the SD Card piece, it is actually more than just an appropriate kernel configuration. We had to port a couple of device drivers from other Linux distributions to make it work with LPC1788.

This feature is not included with Emcraft's Linux Release 1.4. We will be making it available in one of future releases.

If you need SD Card support sooner, please send us a request at Emcraft's support email address and we will give this piece to you separately.

o) Regarding the kernel ticker, you make a good point that Cortex-M could (and probably should) be using the Cortex-M3 SysTick for the Linux timer. It is done the way it is done now because of "historic reasons" of sorts. We based our port of uClinux on the baseline available from the tree at http://www.linux-arm.org, which used a device-specific timer (not SysTick) for the Linux ticker. As always, developing a quick port to our target MCU was a priority so it was easier to use a device-specific timer. I am sure you know how it is :)

We do have a port of our kernel that makes use of the Cortex-M3 SysTick for the ticker. This is for an MCU other than NXP's Cortex-M devices though. We have it on our wish-list to switch to using SysTick across all Cortex-M controllers we support but likely it will have to wait until demand gets more substantial than it is now (you are the first who asked this question externally).

I hope these comments help.

Vladimir
0 Kudos

705 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mcruse on Tue Feb 28 17:13:09 MST 2012
Hi Vladimir,

I purchased and downloaded version 1.4 of the emcraft uClinux port and I have it running. However the default kernel configuration
does not seem to support MMC in the Embedded Artists LPC1788 board.

The mmci-pl18x driver (drivers/mmc/host/mmci.c) depends on ARM_AMBA being enabled. This is not enabled in config ARCH_LPC178X.

Can you share your kernel config file?

Am I missing something else?

I tried checking for a later version but the emcraft web site has been down for two days now.

Are there any updates beyond 1.4?

Regarding the port though, it is quite clean. However I was wondering it you had planned to try using the systick timer for scheduling
rather than Timer0. I started looking at this and I can see that it is a non trivial change since systick is an exception rather than
a normal interrupt. Exceptions having negative ID makes things a little awkward. I had a go at doing this but it might take me a while
to figure out all the details.

Also using Timer1 for a hardware 64 bit timer is a nice idea but the problem is that all of the on chip peripherals related to Timer1
are not really usable as the timer runs very slow due to the large prescale divisor.

It is not such a big issue with Timer0 since it is clocked at the peripheral clock speed but it could be completely freed up if
systick was used for scheduling.

Best regards,

Mike Cruse
0 Kudos