MMC1 boot question

No.  The ROM MMC boot code only supports booting from MMC0.

Regards,
Paul

The TRM shows a sysboot configuration for MMC1 first, then MMC0.

Is this incorrect or did you mean that booting from MMC1 will only work for pinmux MODE1/IO Set 1?

Thanks,

Dave

Opps.  I'm sorry, my comment is not correct.  I was thinking about USB boot and did not look at the TRM.  Let me revaluate your question.

Regards,
Paul

Our board boots from MMC0 (sd card) or MMC1 (eMMC) without any problem.

If interested, I pass you my pinmux (all IO on 3V3)

Regards,

Wim

Thanks Wim,

We had planned to normally boot from MMC0 (SD card) and provide MMC1(SD card) for customer data access.

We hoped MMC1 could provide a solution for fixing a corruption of the MMC0 embedded card if a unit dies in the field (especially on a botched firmware upgrade).

I'll wait to see what the TI crew has to say about the subject.

Dave

Thanks for your help Paul.

I noticed that the u-boot code attaches SDCD to mcasp0_fsx (MODE 4) and WP to uart1_rxd (MODE 1).

The kernel code attaches SDCD to gpmc_advn_ale (MODE 7) and WP to gpmc_csn0 (MODE 7).

Is there a preference?

Based on your comments it sounds like the kernel is using GPIOs for these signals.  I will need to discuss with the software team to determine why they are different.

Regards,
Paul

Paul,

I also have a newbie question. If I boot the board with the MMC1 SD card inserted, the /dev/mmcblk1p1 is created.

However, if booted without the card in place then inserting later, I never 'see' the device.

I've used 'dmesg | tail' and 'fdisk' without success. Is there something wrong in my kernel config or is it a hardware issue?

Dave

I asked a couple of people on the software team if they knew why U-boot and Linux expected the MMC CD and WP signals to be connected to different terminals.  They were not sure and said it may take some time to find someone that understands this difference.

One of the hardware guys told me, previous devices did not have dedicated CD and WP signal functions so they were implemented with GPIO.  Based on this comment it appears the U-boot code has been updated to use the dedicated signal functions in the AM335x and Linux has not been updated.

You last question is related to  the Linux kernel function which I will need to defer to someone on the Linux software team.

Regards,
Paul

I believe the Linux Filesystem that you are testing uses "udev" method to manage connected devices.

Whenever a device is detected, associated dev node is created in /dev directory.

When MMC card inserted or found at boot-up, udev automatically creates /dev/mmcblkXpY node ( x == instance, Y == partition)

So, if no card means no dev node.

Hope i am clear.

Regards

Gururaja

Thanks Gururaja,

To be clear, since we are currently pinmuxed to the internal WP and CD pins using MUX_MODE2, we are unable to use MMC1 as a boot source and also, the card will not be detected after bootup upon insertion.

Since we desire both of these options, we should use the MUX_MODE1 definition and the GPIOs, as done in board-am335xevm.c.

Final questions.

Using the GPIOs for post boot card detect, do we have to poll that line or will the MMC1 setup/init automatically do that for us?

Also, is udev solid with regard to mounting and unmounting based on insertion. I've seen reports to the contrary.

Regards,

Dave

Hello Wim,

I'm trying to test MMC1 boot on my Beaglebone, but not successful yet.

Since you are able to boot from MMC1, one question:
On the hardware end, if I change the SYSBOOT configuration, then the board should boot from MMC1.. right? There is no other change that is required on hardware end.

After making the hardware changes one should expect to see MMC1_CLK signals even without any MMC card (even without any software change).. right?
I do not see any such signals.

Any suggestions/inputs will be of help.

-Prasant

Hello Prasant,

In the Arago kernel provided by TI, the file

 .../board-support/linux-x.x-pspx.x.x.x.sdk/arch/arm/mach-omap2/board-am335xevm.c

must be changed to initialize the properly pinmuxed MMC1 device.

If you have a newer BeagleBone, you must add the line

{mmc1_init, DEV_ON_BASEBOARD, PROFILE_NONE},

to the struct evm_dev_cfg_beaglebone_dev_cfg[].

Be sure to add it before the mmc0_init, as this calls additional setup required for proper mmc1_init.

Then recompile the kernel. Good luck.

Regards, Dave

The Linux code was configured to use GPIOs for the CD and WP signals because the AM335x EVM needed to use the terminals that provided dedicated CD and WP signals for other functions.  The U-boot code had not been updated to match the Linux code.  A patch will be submitted to the U-boot code so it uses the same GPIOs as he Linux code.

You can design your custom hardware to use the dedicated CD and WP signals or GPIOs.  This decision should be based on your pin mux configuration and available pins.  You may need to change the software to match you hardware requirements.

Regards,
Paul