fsl-esdhc on P2020 weird endianess behavior

DISCUSSION Elie De Brauwer 2 participants 8 messages Jan 21, 2011 – Feb 23, 2011

Share & tools

Elie De Brauwer

author

2011-01-21 16:22 UTC #0 lore raw

Hello list,

I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table and ext2ls/fatls are capable of reading the contents of the sd card).

However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa 55 00 00). Also when I try to obtain the card registers they show the same behavior:

# cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
0000b50200000000

While for comparison the same value on my (x86) laptop gives:

edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$ cat scr
02b5000000000000

In my config I have the following set:
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
# CONFIG_MMC_SDHCI_PCI is not set
CONFIG_MMC_SDHCI_OF=y
CONFIG_MMC_SDHCI_OF_ESDHC=y

any pointers are welcome.

gr
E.

Signature · 1 line

Elie De Brauwer

tiejun.chen

2011-01-24 03:24 UTC #1 lore raw

Quoted 9 lines · Elie De Brauwer

Hello list,
I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table and ext2ls/fatls are capable of reading the contents of the sd card).
However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a

Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then I'm a bit curious what it'll be happened.

Quoted 11 lines

hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa 55 00 00). Also when I try to obtain the card registers they show the same behavior:
# cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
0000b50200000000
While for comparison the same value on my (x86) laptop gives:
edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$ cat scr
02b5000000000000

Quoted 7 lines

In my config I have the following set:
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
# CONFIG_MMC_SDHCI_PCI is not set
CONFIG_MMC_SDHCI_OF=y
CONFIG_MMC_SDHCI_OF_ESDHC=y

At least looks the config is fine.

Tiejun

Quoted 7 lines

any pointers are welcome.
gr
E.

Elie De Brauwer

author

2011-01-24 07:52 UTC #2 lore raw

Quoted 8 lines · tiejun.chen

Quoted 7 lines · Elie De Brauwer
Hello list,
I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table and ext2ls/fatls are capable of reading the contents of the sd card).

Quoted 5 lines

Quoted 2 lines
However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a
Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then I'm a bit curious what it'll be happened.

This was already partitioned under (x86) Linux, and when I plug it into my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 command shows the correct partition table). And this does not explain why the card registers (such as the scr pasted below) also seem to have their endianess swapped, which will result in other side-effects, such as improper reading of card capabilities.

Quoted 24 lines

Quoted 12 lines
hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa 55 00 00). Also when I try to obtain the card registers they show the same behavior:
# cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
0000b50200000000
While for comparison the same value on my (x86) laptop gives:
edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$ cat scr
02b5000000000000
Quoted 7 lines
In my config I have the following set:
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
# CONFIG_MMC_SDHCI_PCI is not set
CONFIG_MMC_SDHCI_OF=y
CONFIG_MMC_SDHCI_OF_ESDHC=y
At least looks the config is fine.
Tiejun

tiejun.chen

2011-01-24 08:13 UTC #3 lore raw

Quoted 9 lines · Elie De Brauwer

Quoted 8 lines · tiejun.chen
Quoted 7 lines · Elie De Brauwer
Hello list,
I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table and ext2ls/fatls are capable of reading the contents of the sd card).

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a
Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then
I'm a bit curious what it'll be happened.
This was already partitioned under (x86) Linux, and when I plug it into

I means you should partition the disk on the PPC Linux, not x86. As you know x86 work with LE for Linux, but PPC with BE. So I think you should partition that on the same type machine. Can you try it?

Quoted 2 lines

my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 command shows the correct partition table). And this does not explain

I didn't check this implemented codes within u-boot. Maybe u-boot can do something to swap MMC ending problem. You can try to get the conclusion. Firstly you can re-partition that on PPC Linux then check if u-boot can identify it properly. I guess u-boot still can read that successfully.

Tiejun

Quoted 31 lines

why the card registers (such as the scr pasted below) also seem to have their endianess swapped, which will result in other side-effects, such as improper reading of card capabilities.
Quoted 25 lines
Quoted 13 lines
hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa 55 00 00). Also when I try to obtain the card registers they show the same behavior:
# cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
0000b50200000000
While for comparison the same value on my (x86) laptop gives:
edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$
cat scr
02b5000000000000
Quoted 7 lines
In my config I have the following set:
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
# CONFIG_MMC_SDHCI_PCI is not set
CONFIG_MMC_SDHCI_OF=y
CONFIG_MMC_SDHCI_OF_ESDHC=y
At least looks the config is fine.
Tiejun

Elie De Brauwer

author

2011-01-24 09:04 UTC #4 lore raw

Quoted 23 lines · tiejun.chen

Quoted 9 lines · Elie De Brauwer
Quoted 8 lines · tiejun.chen
Quoted 7 lines · Elie De Brauwer
Hello list,
I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table and ext2ls/fatls are capable of reading the contents of the sd card).
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a
Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then
I'm a bit curious what it'll be happened.
This was already partitioned under (x86) Linux, and when I plug it into
I means you should partition the disk on the PPC Linux, not x86. As you know x86 work with LE for Linux, but PPC with BE. So I think you should partition that on the same type machine. Can you try it?

Quoted 8 lines

Quoted 2 lines
my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 command shows the correct partition table). And this does not explain
I didn't check this implemented codes within u-boot. Maybe u-boot can do something to swap MMC ending problem. You can try to get the conclusion. Firstly you can re-partition that on PPC Linux then check if u-boot can identify it properly. I guess u-boot still can read that successfully.

Unfortunately two wrongs don't make a right here. When I fdisk it on target, then on target the partition gets detected, in u-boot it fails (Unknown partition table). To be honest this was already the behavior which I expected because the endianness swap was also seen for the card registers. So I think something more fundamental is wrong (which in turn smells like the "BIG_ENDIAN_32BIT_BYTE_SWAPPER" but this is used in a very convincing way by the fsl-esdh driver...

Quoted 33 lines

Quoted 32 lines
why the card registers (such as the scr pasted below) also seem to have their endianess swapped, which will result in other side-effects, such as improper reading of card capabilities.
Quoted 25 lines
Quoted 13 lines
hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa 55 00 00). Also when I try to obtain the card registers they show the same behavior:
# cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
0000b50200000000
While for comparison the same value on my (x86) laptop gives:
edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$
cat scr
02b5000000000000
Quoted 7 lines
In my config I have the following set:
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
# CONFIG_MMC_SDHCI_PCI is not set
CONFIG_MMC_SDHCI_OF=y
CONFIG_MMC_SDHCI_OF_ESDHC=y
At least looks the config is fine.
Tiejun

Signature · 1 line

Elie De Brauwer

tiejun.chen

2011-01-24 09:27 UTC #5 lore raw

Quoted 39 lines · Elie De Brauwer

Quoted 30 lines · tiejun.chen
Quoted 14 lines · Elie De Brauwer
Quoted 13 lines · tiejun.chen
Quoted 11 lines · Elie De Brauwer
Hello list,
I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table
and ext2ls/fatls are capable of reading the contents of the sd card).
However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a
Quoted 5 lines
Quoted 3 lines
Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then
I'm a bit curious what it'll be happened.
This was already partitioned under (x86) Linux, and when I plug it into
I means you should partition the disk on the PPC Linux, not x86. As you know x86
work with LE for Linux, but PPC with BE. So I think you should partition that on
the same type machine. Can you try it?
Quoted 2 lines
my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 command shows the correct partition table). And this does not explain
Quoted 7 lines
I didn't check this implemented codes within u-boot. Maybe u-boot can do something to swap MMC ending problem. You can try to get the conclusion. Firstly
you can re-partition that on PPC Linux then check if u-boot can identify it
properly. I guess u-boot still can read that successfully.

Quoted 7 lines

Unfortunately two wrongs don't make a right here. When I fdisk it on target, then on target the partition gets detected, in u-boot it fails (Unknown partition table). To be honest this was already the behavior which I expected because the endianness swap was also seen for the card registers. So I think something more fundamental is wrong (which in turn smells like the "BIG_ENDIAN_32BIT_BYTE_SWAPPER" but this is used in a very convincing way by the fsl-esdh driver...

As you said looks you can disable 'MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER' from the Kconfig to rebuild Linux since its unnecessary for your target.

Tiejun

Quoted 38 lines

Quoted 36 lines
Quoted 35 lines
why the card registers (such as the scr pasted below) also seem to have their endianess swapped, which will result in other side-effects, such as improper reading of card capabilities.
Quoted 27 lines
Quoted 15 lines
hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa
55 00 00). Also when I try to obtain the card registers they show the same behavior:
# cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
0000b50200000000
While for comparison the same value on my (x86) laptop gives:
edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$
cat scr
02b5000000000000
Quoted 7 lines
In my config I have the following set:
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
# CONFIG_MMC_SDHCI_PCI is not set
CONFIG_MMC_SDHCI_OF=y
CONFIG_MMC_SDHCI_OF_ESDHC=y
At least looks the config is fine.
Tiejun

Elie De Brauwer

author

2011-01-24 09:36 UTC #6 lore raw

Quoted 48 lines · tiejun.chen

Quoted 39 lines · Elie De Brauwer
Quoted 30 lines · tiejun.chen
Quoted 14 lines · Elie De Brauwer
Quoted 13 lines · tiejun.chen
Quoted 11 lines · Elie De Brauwer
Hello list,
I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table
and ext2ls/fatls are capable of reading the contents of the sd card).
However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a
Quoted 5 lines
Quoted 3 lines
Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then
I'm a bit curious what it'll be happened.
This was already partitioned under (x86) Linux, and when I plug it into
I means you should partition the disk on the PPC Linux, not x86. As you know x86
work with LE for Linux, but PPC with BE. So I think you should partition that on
the same type machine. Can you try it?
Quoted 2 lines
my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 command shows the correct partition table). And this does not explain
Quoted 7 lines
I didn't check this implemented codes within u-boot. Maybe u-boot can do something to swap MMC ending problem. You can try to get the conclusion. Firstly
you can re-partition that on PPC Linux then check if u-boot can identify it
properly. I guess u-boot still can read that successfully.
Quoted 7 lines
Unfortunately two wrongs don't make a right here. When I fdisk it on target, then on target the partition gets detected, in u-boot it fails (Unknown partition table). To be honest this was already the behavior which I expected because the endianness swap was also seen for the card registers. So I think something more fundamental is wrong (which in turn smells like the "BIG_ENDIAN_32BIT_BYTE_SWAPPER" but this is used in a very convincing way by the fsl-esdh driver...

Quoted 3 lines

As you said looks you can disable 'MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER' from the Kconfig to rebuild Linux since its unnecessary for your target.

Well no, since this gets selected by the fsl-esdhc driver

config MMC_SDHCI_OF_ESDHC
bool "SDHCI OF support for the Freescale eSDHC controller" depends on MMC_SDHCI_OF
select MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER help
This selects the Freescale eSDHC controller support.

If unsure, say N.

And if you look in the sdhc-of.esdhc.c (http://lxr.linux.no/#linux+v2.6.37/drivers/mmc/host/sdhci-of-esdhc.c#L75 ) you can see that this driver is very stubborn in using the sdhci_be32bs* variants, so it just won't compile without the BYTE_SWAPPER set. But the entire sdhci_esdhc struct looks odd (for example they do byteswapping for the read_b but nog for the write_b, and it gets only done for the {read|write}_l. I'll try using the 'regular' callbacks here instead of the byteswapped versions.

Quoted 41 lines

Tiejun
Quoted 38 lines
Quoted 36 lines
Quoted 35 lines
why the card registers (such as the scr pasted below) also seem to have their endianess swapped, which will result in other side-effects, such as improper reading of card capabilities.
Quoted 27 lines
Quoted 15 lines
hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa
55 00 00). Also when I try to obtain the card registers they show the same behavior:
# cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
0000b50200000000
While for comparison the same value on my (x86) laptop gives:
edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$
cat scr
02b5000000000000
Quoted 7 lines
In my config I have the following set:
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
# CONFIG_MMC_SDHCI_PCI is not set
CONFIG_MMC_SDHCI_OF=y
CONFIG_MMC_SDHCI_OF_ESDHC=y
At least looks the config is fine.
Tiejun

Signature · 1 line

Elie De Brauwer

Elie De Brauwer

author

2011-02-23 15:19 UTC #7 lore raw

In reply to Elie De Brauwer

Quoted 20 lines · Elie De Brauwer

Hello list,
I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table and ext2ls/fatls are capable of reading the contents of the sd card).
However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa 55 00 00). Also when I try to obtain the card registers they show the same behavior:
# cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
0000b50200000000
While for comparison the same value on my (x86) laptop gives:
edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$ cat scr
02b5000000000000

Quoted 8 lines

In my config I have the following set:
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
# CONFIG_MMC_SDHCI_PCI is not set
CONFIG_MMC_SDHCI_OF=y
CONFIG_MMC_SDHCI_OF_ESDHC=y

In the meantime I've 'downgraded' this issue away. Just to share my conclusions with the world (and perhaps somebody has an aha-erlebnis when reading this which can identify the root cause). I did some triaging today and found out the issue was present in 2.6.36 and 2.6.36.4 but it was not present in 2.6.35.9.

The CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER is not involved because this relates to the way the registers on the SoC are accessed, these registers are accessed in the correct way. The problem only occurs when accessing data from the SD card (e.g. the SCR which is a card register, but also the MBR).

Signature · 1 line

Elie De Brauwer