Booting from MMC1

Please do not hijack an email thread. it is very rude. Start a fresh one for your topic. But before you do that, try the following link.

http://circuitco.com/support/index.php?title=Main_Page

Gerald

The one line change, that I assume you're referring to with the
PULLDOWN is just for the write protect line, which later in that diff
gets disabled.

I'm able to boot with MMC1 being detected without issue making similar
modifications to what Joel did (basically just enabling the existing
MMC1 pin-mux and init that was in the evm defconfig).

Can you put a logic analyzer on it to see if the pins are dancing the
right way?

Have you tried any different cards?

If you set the boot mode resistors properly to boot from MMC1, u-boot
mainline will boot, although the default is to load the kernel and
set root as mmc0 (easily fixed with a small change and recompile).

-Andrew

bootlog snippet from me (card in MMC1 isn't formatted):

[ 1.119360] Waiting for root device /dev/mmcblk0p2...
[ 1.185060] mmc0: host does not support reading read-only switch. assuming write-enable.
[ 1.196961] mmc0: new high speed SDHC card at address e624
[ 1.203462] mmcblk0: mmc0:e624 SU04G 3.69 GiB
[ 1.211382] mmcblk0: p1 p2
[ 1.244518] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 1.253106] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 1.261828] devtmpfs: mounted
[ 1.265354] Freeing init memory: 192K
[ 1.298836] mmc1: host does not support reading read-only switch. assuming write-enable.
[ 1.309296] mmc1: new high speed SDHC card at address b368
[ 1.316513] mmcblk1: mmc1:b368 00000 7.51 GiB
[ 1.323723] mmcblk1: unknown partition table

Hello Andrew,

Hello Joel,

>> Now I'm stuck at the following point:
> [..]
>
>> [ 1.720611] Waiting for root device /dev/mmcblk0p2...
>> [ 12.377655] mmc1: new high speed SD card at address 0002
>> [ 12.383972] mmcblk0: mmc1:0002 00000 1.86 GiB (ro)
>>
>> Does anybody have any clue about how to fix it?
>
> Can you describe what you mean by stuck? Do you see any processes
> in a D state (ps aux|grep D). I am concerned that the MMC host
> controller is waiting for a response to a command that the MMC card
> didn't get.

My system cannot boot with MMC1.

After these last messages, the filesystem doesn't execute.

At first, I thought that the mmcblk driver shoud be 1 instead of 0.
But I saw that mmcblk0 is not a problem with mmc1.

I have the same feeling as you have (communication issue). But, as
until now it is working, I believe the hardware is fine.

>
> I faced a similar problem when enabling MMC1 on beaglebone hardware.
> Did you enable pinmuxing correctly? Can you post the changes you
> made to the kernel to get MMC1 working?

On next email :slight_smile:

>
> Refer to this patch that gets MMC1 working with AM33XX:
> emmc: Enable pinmuxing and emmc config for Beaglebone LT eMMC module · joelagnel/linux-kernel@eb2de2d · GitHub

In my changes, I use the mmc1 configuration already present in the
kernel code, but I used a PULLUP configuration, instead of your
PULLDOWN configuration. Maybe it helps ...

The one line change, that I assume you're referring to with the
PULLDOWN is just for the write protect line, which later in that diff
gets disabled.

I'm able to boot with MMC1 being detected without issue making similar
modifications to what Joel did (basically just enabling the existing
MMC1 pin-mux and init that was in the evm defconfig).

I'm using the same approach as you.

Can you put a logic analyzer on it to see if the pins are dancing the
right way?

Unfortunatelly not ... at least, not now ...

Have you tried any different cards?

Yes. With the same results.

If you set the boot mode resistors properly to boot from MMC1, u-boot
mainline will boot, although the default is to load the kernel and
set root as mmc0 (easily fixed with a small change and recompile).

I changed the boot resistor to MMC1. It works well for U-BOOT. But,
for Linux, it detects the mmc, but there is some communication issue
that I could not solve already.

-Andrew

bootlog snippet from me (card in MMC1 isn't formatted):

[ 1.119360] Waiting for root device /dev/mmcblk0p2...
[ 1.185060] mmc0: host does not support reading read-only switch. assuming write-enable.
[ 1.196961] mmc0: new high speed SDHC card at address e624
[ 1.203462] mmcblk0: mmc0:e624 SU04G 3.69 GiB
[ 1.211382] mmcblk0: p1 p2
[ 1.244518] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 1.253106] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 1.261828] devtmpfs: mounted
[ 1.265354] Freeing init memory: 192K
[ 1.298836] mmc1: host does not support reading read-only switch. assuming write-enable.
[ 1.309296] mmc1: new high speed SDHC card at address b368
[ 1.316513] mmcblk1: mmc1:b368 00000 7.51 GiB
[ 1.323723] mmcblk1: unknown partition table

Best regards,

Flavio

Hardware should be "roughly right," then...

Can you mail or pastebin your board file? Sorry if you already did,
if so, can you link to it?

-Andrew

Hello Koen,

I have a test disabling the SPI subsystem from kernel and it doesn’t work.

It seems to be a problem with high speed communication. I’ll check the hardware.

Every new idea is welcome :slight_smile:

Best regards,

Flavio

See below for full boot log of successful mmc1 boot (no mmc0 card
present on board) of Debian on a bone with custom cape. Running
mainline u-boot (with my uart and mmc patches plus small tweaks to
the config) and the evil vendor kernel (with small modifications).

I believe you have a hardware problem.

-Andrew

U-Boot 2012.10-rc2-00009-g7985a52-dirty (Oct 05 2012 - 08:56:24)

I2C: ready
DRAM: 256 MiB
WARNING: Caches not enabled
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net: cpsw
Hit any key to stop autoboot: 0
mmc1 is current device
SD/MMC found on device 1
reading uEnv.txt

470 bytes read
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
Loading file "/boot/firstboot" from mmc device 1:2
** File not found /boot/firstboot
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading kernel from TFTP
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.101.18
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.101.1; our IP address is 192.168.101.18
Filename 'uImage'.
Load address: 0x80200000
Loading: #################################################################

Debugging cutom HW by email is challanging.

flavio have you probed the realevent pins with a scope?

Hello Mark,

From: Andrew Bradford <andrew@bradfordembedded.com>
Subject: Re: [beagleboard] Booting from MMC1
To: beagleboard@googlegroups.com
Cc: flavio.alves@gmail.com
Date: Friday, October 5, 2012, 8:09 AM

> I have a test disabling the SPI subsystem from kernel
and it doesn't
> work.
>
> It seems to be a problem with high speed
communication. I'll check
> the hardware.
>
> Every new idea is welcome :slight_smile:

See below for full boot log of successful mmc1 boot (no mmc0
card
present on board) of Debian on a bone with custom
cape. Running
mainline u-boot (with my uart and mmc patches plus small
tweaks to
the config) and the evil vendor kernel (with small
modifications).

I believe you have a hardware problem.

-Andrew

Debugging cutom HW by email is challanging.

flavio have you probed the realevent pins with a scope?

Not yet. I intend to do so this weekend and send you the result with a
picture of the board. I don't have a schematic, because it was made
"by hand" :slight_smile:

--

Best regards,

Flavio