I've run Tiny Core 9.0 from a USB pendrive without any problems.
One thing to note is that the eMMC Flash memory does not appear as the more usual /dev/sda device. In the dmesg output I find:
..... mmc0: SDHCI controller on PCI [0000:00:17.0] using ADMA mmc0: new DDR MMC card at address 0001 ...... mmcblk0: mmc0:0001 SEM04G 3.69 GiB mmcblk0boot0: mmc0:0001 SEM04G partition 1 2.00 MiB mmcblk0boot1: mmc0:0001 SEM04G partition 2 2.00 MiB mmcblk0rpmb: mmc0:0001 SEM04G partition 3 2.00 MiB mmcblk0: p1 ...... FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. ...... FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Looking in the /dev directory I find:
brw-rw---- 1 root staff 179, 0 May 13 16:25 /dev/mmcblk0 brw-rw---- 1 root staff 179, 8 May 13 16:25 /dev/mmcblk0boot0 brw-rw---- 1 root staff 179, 16 May 13 16:25 /dev/mmcblk0boot1 brw-rw---- 1 root staff 179, 1 May 13 16:25 /dev/mmcblk0p1 brw-rw---- 1 root staff 179, 24 May 13 16:25 /dev/mmcblk0rpmb
I haven't really explored the characteristics of eMMC devices but I did come across a comment that
"eMMC supports separate boot partitions for storing the bootloader. They are not sharing the same block device with the data."
which may go towards explaining the number of devices listed. Normally we have something like:
/dev/sda - the device
/dev/sda1 - the partition on the device.
As mentioned above I haven't explored the ins and outs of using the onboard flash other than a brief unsuccessful attempt to use fsck on it to remove the complaint shown above. That bombed out with:
Warning: fsck.vfat /dev/mmcblk0p1 terminated by signal 1