public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Elie De Brauwer <eliedebrauwer@gmail•com>
To: linuxppc-dev@lists•ozlabs.org
Cc: "tiejun.chen" <tiejun.chen@windriver•com>
Subject: Re: fsl-esdhc on P2020 weird endianess behavior
Date: Mon, 24 Jan 2011 10:03:57 +0100	[thread overview]
Message-ID: <4D3D407D.4080800@gmail.com> (raw)
In-Reply-To: <4D3D3512.4020105@windriver.com>

On 01/24/11 09:15, tiejun.chen wrote:
> Elie De Brauwer wrote:
>> On 01/24/11 04:26, tiejun.chen wrote:
>>> Elie De Brauwer wrote:
>>>> 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.
>>
>> 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?
>
>> 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...

>
>> 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.
>>
>>>
>>>> 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
>>>
>>> At least looks the config is fine.
>>>
>>> Tiejun
>>>
>>
>>
>


-- 
Elie De Brauwer

  reply	other threads:[~2011-01-24  9:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-21 16:22 fsl-esdhc on P2020 weird endianess behavior Elie De Brauwer
2011-01-24  3:26 ` tiejun.chen
2011-01-24  7:52   ` Elie De Brauwer
2011-01-24  8:15     ` tiejun.chen
2011-01-24  9:03       ` Elie De Brauwer [this message]
2011-01-24  9:28         ` tiejun.chen
2011-01-24  9:36           ` Elie De Brauwer
2011-02-23 15:19 ` Elie De Brauwer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D3D407D.4080800@gmail.com \
    --to=eliedebrauwer@gmail$(echo .)com \
    --cc=linuxppc-dev@lists$(echo .)ozlabs.org \
    --cc=tiejun.chen@windriver$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox