the way to set MMC mode(8-bit transfer) and 384Mbps at BBBW

[ha ppay]

Hi Everyone.
I'm collecting information to get even faster boot times,
I have 2 questions.
It is written that it is possible to boot from MMC (8bit mode) (18.1.1 MMCHS Features) using MMC mode with TRM of am335x.

- Clock support
  -96-MHz functional clock source input
  -up to 384Mbit/sec (48MByte/sec) in MMC mode 8-bit data transfer
  -up to 192Mbit/sec (24MByte/sec) in High-Speed SD mode 4-bit data transfer
  -up to 24Mbit/sec (3MByte/sec) in Default SD mode 1-bit data transfer

Also, the SD_CON register DW8 Field has a flag for it.
I expect this setting to start up much faster.
In BBB, how do I set it to 8bit mode and how do I set the frequency to 384Mbit / sec (is it mmc_clk/clock-div in Devicetree?)?

Regards,

BBB User A.

[ha ppay]

Hi Everyone,

Does anyone know any good methods or tips for finding out?

Reagards,
BBBW User A.

2021年2月18日木曜日 16:10:53 UTC+9 ha ppay:

[jeff....@gmail.com]

Hi when you say you're collecting information for faster boot times, can you tell us more about what OS and FS you're running?  Why are you focusing solely on speeding up the hardware as opposed to ways to make u-boot and the kernel to boot faster, for instance?

Here's a prior post on speeding up boot times:

https://groups.google.com/g/beagleboard/c/RGbTFHQOj2E

[Robert Nelson]

It's already in 8-bit mode..

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am335x-boneblack-common.dtsi#n23

&mmc2 {
vmmc-supply = <&vmmcsd_fixed>;
pinctrl-names = "default";
pinctrl-0 = <&emmc_pins>;
bus-width = <8>;
status = "okay";
non-removable;
};

Regards,

--
Robert Nelson
https://rcn-ee.com/

[ha ppay]

Hi Jeff,

Thank you for your reply.

>Hi when you say you're collecting information for faster boot times, can you tell us more about what OS and FS you're running?

Functions I require are emmc, i2c, uart, gpio, wlan, adc.

===results of Version.sh================================================================================================
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLTBWA52010BBWG0277]
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
kernel:[4.19.94-ti-r42]
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.14.20200403.0-0rcnee0~buster+20200403]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[   19.613520] remoteproc remoteproc0: 4a334000.pru is available
[   19.625567] remoteproc remoteproc1: 4a338000.pru is available
[   85.818817] remoteproc remoteproc2: wkup_m3 is available
[   85.828262] remoteproc remoteproc2: powering up wkup_m3
[   85.828300] remoteproc remoteproc2: Booting fw image am335x-pm-firmware.elf, size 217168
[   85.828581] remoteproc remoteproc2: remote processor wkup_m3 is now up
dmesg | grep pru
[   19.613520] remoteproc remoteproc0: 4a334000.pru is available
[   19.613727] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed successfully
[   19.625567] remoteproc remoteproc1: 4a338000.pru is available
[   19.625765] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed successfully
dmesg | grep pinctrl-single
[    0.930015] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[    0.943259] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

===================================================================================================================

>Why are you focusing solely on speeding up the hardware as opposed to ways to make u-boot and the kernel to boot faster, for instance?

I use BBBW as an evaluation board for am3351.
Among them, I'm simply looking for a faster boot time. Setting up the kernel and uboot was a bit difficult for me now.
While reading the am335x TRM, I found the MMC transfer rate setting in the MMCHS description.
For confirmation, I wrote the same image to the SD card and eMMC and compared the BOOT time, and the result was that eMMC was only a few seconds faster.
If the MMC was in 8-bit mode, I thought it would be faster, and I wondered if both were running in 4-bit mode.
When I added initcall_debug to the kernel command line and booted from the SD card, I got the following log.
I thought this log had the transfer rate set to high speed (4-bit Mode) for both SDHC and MMC.

2021年2月23日火曜日 0:42:12 UTC+9 RobertCNelson:

[ha ppay]

Hi RobertCNelson,

Thank you for checking the relevant part.
the description of the Device tree is as follows. Is this overwriting the setting? In fact, when I set this part to
bus-width = <0x08>
, the Boot time did not change much.

Could you tell me if there is a way to check the current transfer bit mode?

  mmc@48060000 {
   compatible = "ti,omap4-hsmmc";
   ti,hwmods = "mmc1";
   ti,dual-volt;
   ti,needs-special-reset;
   ti,needs-special-hs-handling;
   dmas = < 0x2d 0x18 0x00 0x00 0x2d 0x19 0x00 0x00 >;
   dma-names = "tx\0rx";
   interrupts = < 0x40 >;
   reg = < 0x48060000 0x1000 >;
   status = "okay";
   bus-width = < 0x04 >;                        <=======
   pinctrl-names = "default";
   pinctrl-0 = < 0x2e >;
   cd-gpios = < 0x2f 0x06 0x01 >;
   vmmc-supply = < 0x30 >;
   phandle = < 0x288 >;
  };

Regards,

2021年2月23日火曜日 0:42:12 UTC+9 RobertCNelson:

On Thu, Feb 18, 2021 at 1:10 AM ha ppay <ando...@gmail.com> wrote:

[Robert Nelson]

On Mon, Feb 22, 2021 at 8:34 PM ha ppay <ando...@gmail.com> wrote:
>
> Hi RobertCNelson,
>
> Thank you for checking the relevant part.
> the description of the Device tree is as follows. Is this overwriting the setting? In fact, when I set this part to
> bus-width = <0x08>
> , the Boot time did not change much.
> Could you tell me if there is a way to check the current transfer bit mode?
>
>
> mmc@48060000 {
> compatible = "ti,omap4-hsmmc";
> ti,hwmods = "mmc1";
> ti,dual-volt;
> ti,needs-special-reset;
> ti,needs-special-hs-handling;
> dmas = < 0x2d 0x18 0x00 0x00 0x2d 0x19 0x00 0x00 >;
> dma-names = "tx\0rx";
> interrupts = < 0x40 >;
> reg = < 0x48060000 0x1000 >;
> status = "okay";
> bus-width = < 0x04 >; <=======
> pinctrl-names = "default";
> pinctrl-0 = < 0x2e >;
> cd-gpios = < 0x2f 0x06 0x01 >;
> vmmc-supply = < 0x30 >;
> phandle = < 0x288 >;
> };

Well, mmc@48060000 -> is the microSD on the BBBW -> which only has 4
data wires hooked up...

So, yeah, that won't change the eMMC..

PS, the factory default eMMC on these boards isn't known for speed,
the version used is more for reliability..

You can buy pretty cheap fast microSD on a 4-bit bus that will outpace
the factory default eMMC on a 8-bit bus..

[Dennis Lee Bieber]

On Mon, 22 Feb 2021 18:20:16 -0800 (PST), in
gmane.comp.hardware.beagleboard.user ha ppay

<andocn777-Re5JQE...@public.gmane.org> wrote:


>For confirmation, I wrote the same image to the SD card and eMMC and
>compared the BOOT time, and the result was that eMMC was only a few seconds
>faster.

Not a valid test without knowing the details of the uSD card -- in
particular how many open "allocation units" the card supports. Cheaper
cards support only two AUs -- which is compatible with the non-journalling
FAT file system (one unit for current data file, one unit for maintaining
the FAT itself); using a journalling file system (ext4, say), can result in
a lot of flushing and loading of AUs (most impact for writing, but still
has some as the file system has to track directory files, map to inodes,
and from there to actual data blocks).

The cheaper Class-10 cards are especially bad at this, as the Class-10
rating was based upon streaming a single file (video) to/from a freshly
formatted card, whereas Class-2/4/6 are rated on transferring smaller files
(still image photos) to/from a fragmented file system (as if one has
deleted a few photos leaving gaps).

Repeating something I posted start of the month:

-=-=-=-

Note that "Class 10" cards are speed rated for STREAMING a single file
to/from a freshly formatted card (eg: video). "Class 2/4/6" cards are rated
for multiple small file writes&reads with fragmentation (eg: still photo
camera with some images deleted). Also note that all such are based upon
FAT file system -- not a journaling system.

Some card makers of "Class 10" cards take advantage of this, and fit
controllers on the card that can only track TWO "open" "allocation units"
-- the FAT table, and the data file. Every time the filesystem has to open
another file (and that happens a lot with journals -- write new contents
somewhere, write metadata to journal, sometime later wipe out original
metadata, followed by writing journal metadata and deleting journal) it has
to obtain a new allocation unit -- this involves closing and flushing the
current allocation unit to the memory, finding and erasing a free
allocation unit (erase is slow, as it has to set every bit in the unit to
"1" -- writing can only toggle a "1" bit to a "0"), then copying unchanged
data that might be in an old allocation unit before writing new data to
that unit.

Better cards will support 4 to 6 simultaneous open allocation units,
meaning one can be updating multiple files in parallel without forcing
erase cycles and copying partial units around.

From a post I made last March

>From a post (of mine) on the R-Pi group... Running the "Raspberry Pi
>Dramble microSD benchmarks".
>curl
>https://raw.githubusercontent.com/geerlingguy/raspberry-pi-dramble/master/setup/benchmarks/microsd-benchmarks.sh
>>benchmark.sh
>
>"bdr-" is the "buffered disk read" from hdparm
>"dd-" are, well, "dd"
>The rest are "iozone" results.
>
>The BBB has
> SanDisk Edge 8GB Class 4 HC I8227DTJLT009
>Not sure of the eMMC version
>The R-Pi3B+ has
> Kingston 16GB Class 10 HC I U1 SDC10G2/16GB N0581-002.A00LF
>
>
>metric BBB (SD) RPi3B+ eMMC
>bdr-MB 21.74 21.97 hdparm did not run (tried to access SD)*
>dd-sec 89.4367 67.4917 63.8932
>dd-MB 4.7 6.2 6.6
>write 1652 250 1814
>rewrite 2306 237 1888
>read 6371 5814 5039
>reread 6375 5798 5038
>ranread 5364 5138 3562
>ranwrite 1157 234 395
>
> The Class 4 SanDisk, in the 1GHz single-core BBB readily beat the Class
>10 Kingston in a 1.4GHz quad-core R-Pi3B+ in any meaningful test (the
>Kingston only won out on the "bdr" and "dd" test cases, and the BBB eMMC
>beat it on the "dd" test). {Note: I just reran on the SD card, and
>"write"/"rewrite" only showed 405/284, which still beats the Class 10 --
>suspect if I redid the test it might improve as the SD card may have
>remnants getting reused)

The SanDisk Class 4 was easily 8 times faster than the Kingston Class
10 for regular write, rewrite, and random write, and was also faster (if
not as much) for read/reread/random read.




--
Dennis L Bieber

[ha ppay]

Hi,
I forgot attaching kernel log.

I don't know if I can add it by replying to the comment, but I will challenge it.
I thought that the SDHC/MMC are type of media, and "high speed"  indicates 4-bit mode.

[    1.086202] mmc0: new high speed SDHC card at address 0001
[    1.091531] mmcblk0: mmc0:0001 ASTC 29.0 GiB
    
[    1.118517] mmc1: new high speed MMC card at address 0001
[    1.123897] mmcblk1: mmc1:0001 M62704 3.56 GiB

regards,

2021年2月23日火曜日 11:20:26 UTC+9 ha ppay:

[Dennis Lee Bieber]

On Tue, 23 Feb 2021 15:40:22 -0800 (PST), in

gmane.comp.hardware.beagleboard.user ha ppay
<andocn777-Re5JQE...@public.gmane.org> wrote:

>I thought that the SDHC/MMC are type of media, and "high speed" indicates
>4-bit mode.

https://en.wikipedia.org/wiki/MultiMediaCard#Table
For the most part, high speed is likely any mode that is not using a single
data line (1-bit) mode. eMMC is based on an 8-bit mode, and does not
support 1-bit SPI mode. SDxx supports 1-bit (both SPI and MMC) modes, and
4-bit mode -- but does not support an 8-bit mode (not enough pins)


--
Dennis L Bieber

[ha ppay]

Hi RobertCNelson,

I recently knew that the SD card was just one type of MMC, but I just made a mistake. Thank you for your advice.
yes, I knew that the am335x MMCHS supports up to 4-bit mode on SD cards.

>PS, the factory default eMMC on these boards isn't known for speed,
>the version used is more for reliability.

The eMMC configured in bbb may be doing a good job in terms of price, but ...

>You can buy pretty cheap fast microSD on a 4-bit bus that will outpace
>the factory default eMMC on a 8-bit bus..

I didn't really think that the types and manufacture of SD cards and MMCs could affect the transfer speed so much.

regards,

2021年2月23日火曜日 11:40:46 UTC+9 RobertCNelson:

[Robert Nelson]

On Tue, Feb 23, 2021 at 5:40 PM ha ppay <ando...@gmail.com> wrote:
>
> Hi,
> I forgot attaching kernel log.
> I don't know if I can add it by replying to the comment, but I will challenge it.
> I thought that the SDHC/MMC are type of media, and "high speed" indicates 4-bit mode.
> [ 1.086202] mmc0: new high speed SDHC card at address 0001
> [ 1.091531] mmcblk0: mmc0:0001 ASTC 29.0 GiB
>
> [ 1.118517] mmc1: new high speed MMC card at address 0001
> [ 1.123897] mmcblk1: mmc1:0001 M62704 3.56 GiB

"NO"... "high speed" doesn't mean anything on "bit-ness"..

https://elixir.bootlin.com/linux/v5.11/source/drivers/mmc/core/bus.c#L366

https://elixir.bootlin.com/linux/v5.11/source/include/linux/mmc/host.h#L575

So it's stuck in MMC_TIMING_SD_HS/MMC_TIMING_MMC_HS timings..

You don't get SDR12/DDR50 mode till mmc_card_uhs and then it would say:

[ 1.086202] mmc0: new ultra high speed SDHC card at address 0001

either way, your eMMC is still in 8-bit mode..

BUS width just changes how the data is communicated..

https://elixir.bootlin.com/linux/v5.11/C/ident/MMC_BUS_WIDTH_8

[Robert Nelson]

On Tue, Feb 23, 2021 at 5:59 PM ha ppay <ando...@gmail.com> wrote:
>
> Hi RobertCNelson,
>

> I recently knew that the SD card was just one type of MMC, but I just made a mistake. Thank you for your advice.
> yes, I knew that the am335x MMCHS supports up to 4-bit mode on SD cards.

PS you can cat the debugfs to find out what mode this is in:

MicroSD: 4-bit mode
debian@bbb-pwr01-ser09:~$ sudo cat /sys/kernel/debug/mmc0/ios
clock: 50000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)

eMMC: 8-bit mode
debian@bbb-pwr01-ser09:~$ sudo cat /sys/kernel/debug/mmc1/ios
clock: 52000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 3 (8 bits)
timing spec: 1 (mmc high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)

If you can't read that, then update your fstab:

debian@bbb-pwr01-ser09:~$ cat /etc/fstab | grep debug
debugfs /sys/kernel/debug debugfs mode=755,uid=root,gid=gpio,defaults 0 0

[ha ppay]

Hi Dennis Bieber

Thank you for the detailed explanation of the SD card standard (class) and features.

>The SanDisk Class 4 was easily 8 times faster than the Kingston Class
>10 for regular write, rewrite, and random write, and was also faster (if
>not as much) for read/reread/random read.

We will use it as a reference when selecting an SD card.
It turns out that like SD cards, MMCs have completely different transfer rates.

>https://en.wikipedia.org/wiki/MultiMediaCard#Table
so many version...

Is the transfer speed of MMC completely different like SD card? 

regards,

2021年2月24日水曜日 9:07:48 UTC+9 RobertCNelson:

[ha ppay]

Hi RobertCNelson

Thank you for your confirmation. 

I checked my bbb, 

My eMMC was 8-bit Mode clearly.

sudo cat /sys/kernel/debug/mmc0/ios   
clock:          50000000 Hz   
vdd:            21 (3.3 ~ 3.4 V)   
bus mode:       2 (push-pull)   
chip select:    0 (don't care)   
power mode:     2 (on)   
bus width:      2 (4 bits)   
timing spec:    2 (sd high-speed)   
signal voltage: 0 (3.30 V)   
driver type:    0 (driver type B)   
   

sudo cat /sys/kernel/debug/mmc1/ios   
clock:          52000000 Hz   
vdd:            21 (3.3 ~ 3.4 V)   
bus mode:       2 (push-pull)   
chip select:    0 (don't care)   
power mode:     2 (on)   
bus width:      3 (8 bits)   
timing spec:    1 (mmc high-speed)   
signal voltage: 0 (3.30 V)   
driver type:    0 (driver type B)   

regards,

2021年2月24日水曜日 11:30:50 UTC+9 ha ppay:

[Dennis Lee Bieber]

On Tue, 23 Feb 2021 18:30:40 -0800 (PST), in

gmane.comp.hardware.beagleboard.user ha ppay
<andocn777-Re5JQE...@public.gmane.org> wrote:

>Hi Dennis Bieber
>
>Thank you for the detailed explanation of the SD card standard (class) and
>features.
>
>>The SanDisk Class 4 was easily 8 times faster than the Kingston Class
>>10 for regular write, rewrite, and random write, and was also faster (if
>>not as much) for read/reread/random read.
>We will use it as a reference when selecting an SD card.
>It turns out that like SD cards, MMCs have completely different transfer
>rates.
>>https://en.wikipedia.org/wiki/MultiMediaCard#Table
>so many version...
>Is the transfer speed of MMC completely different like SD card?
>

I would suspect the primary factor is the on-chip /controller/ section
-- which is responsible for handling the erasure/reuse of allocation units.
There may be some effect if the flash memory itself is NAND or NOR type.

See https://www.pidramble.com/wiki/benchmarks/microsd-cards

While that site is focused on the Raspberry Pi, the benchmarks WILL run
on a Beaglebone (though one test won't run on the eMMC -- the script is
still trying to access the SD card for that test).


--
Dennis L Bieber

[ha ppay]

Hi RobertCNelson,

>PS, the factory default eMMC on these boards isn't known for speed,
>the version used is more for reliability..

I understand that the default eMMC on the board is unpublished in speed and version and unreliable, is that correct?
If the eMMC or Data Bus Width is HS400 Mode 8bit or Clock Frequency is 200MHz, does it need to be set and the startup speed is even faster? 

Regards,

2021年2月24日水曜日 13:22:50 UTC+9 Dennis Bieber:

[Dennis Lee Bieber]

On Wed, 24 Feb 2021 22:40:45 -0800 (PST), in

gmane.comp.hardware.beagleboard.user ha ppay
<andocn777-Re5JQE...@public.gmane.org> wrote:

>I understand that the default eMMC on the board is unpublished in speed and
>version and unreliable, is that correct?

Pardon... The eMMC used was chosen BECAUSE it is RELIABLE. However, the
more reliable flash memories tend to be slower.

Technically NOT "unpublished" either since you should be able to look
up the specification sheet for the eMMC chip on your board (mine has the
Micron chip:
https://www.datasheet4u.com/datasheet-pdf/Micron/MTFC4GLDEA-0M-WT/pdf.php?id=1025550
there is a PDF linked lower on that page for the 26 page data sheet).

It is SD cards that are difficult to find specifications for as makers
may keep the same "name/part" but change out the internals. eMMC, OTOH,
tend to be ordered /by/ manufacturers and they specify performance when
doing so.


--
Dennis L Bieber

[Robert Nelson]

On Thu, Feb 25, 2021 at 12:40 AM ha ppay <ando...@gmail.com> wrote:
>
> Hi RobertCNelson,
>
> >PS, the factory default eMMC on these boards isn't known for speed,
> >the version used is more for reliability..
> I understand that the default eMMC on the board is unpublished in speed and version and unreliable, is that correct?
> If the eMMC or Data Bus Width is HS400 Mode 8bit or Clock Frequency is 200MHz, does it need to be set and the startup speed is even faster?

Currently, all boards are built with Kingston EMMC04G-M627:

https://www.kingston.com/unitedstates/en/embedded/emmc-embedded-flash

This is a 4GB 5.0/5.1(HS400) MLC device

The TI AM335x fully supports eMMC 4.3 spec:

https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf

Attached a screenshot of the page..

Then finally 4.3 vs 5.1:

https://www.datalight.com/solutions/technologies/emmc/emmc-feature-comparison-by-version

HS200 was added in 4.5..

The AM335x IP was designed for 4.3 before 4.5 came out..

Sorry, Time Travel still isn't viable in Semiconductor Production..