Re: [U-Boot] [PATCH] part: check each variable for capability calculation
Since last month, no any feedback.
Who can give some comment about this patch?
Best Regards
Jerry Huang
> -Original Message-
> From: Huang Changming-R66093
> Sent: Wednesday, November 07, 2012 9:33 AM
> To: u-boot@lists.denx.de
> Cc: Huang Changming-R66093
> Subject: [PATCH] part: check each variable for capability calculation
>
> From: Jerry Huang
>
> In order to calculate the capability, we use the below expression to
> check:
> ((dev_desc->lba * dev_desc->blksz)>0L)
> If the capability is greater than 4GB (e.g. 8GB = 8 * 1024 * 104 * 1024),
> the result will overflow, the low 32bit may be zero.
>
> Therefore, change to check each variable to fix this potential issue.
>
> Signed-off-by: Jerry Huang
> ---
> disk/part.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/disk/part.c b/disk/part.c
> index 4646f68..7bdc90e 100644
> --- a/disk/part.c
> +++ b/disk/part.c
> @@ -199,7 +199,7 @@ void dev_print (block_dev_desc_t *dev_desc)
> break;
> }
> puts ("\n");
> - if ((dev_desc->lba * dev_desc->blksz)>0L) {
> + if (dev_desc->lba > 0L && dev_desc->blksz > 0L) {
> ulong mb, mb_quot, mb_rem, gb, gb_quot, gb_rem;
> lbaint_t lba;
>
> --
> 1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/esdhc: force the bus width to 4bit
Thanks, Jaehoon, I saw it. Best Regards Jerry Huang > -Original Message- > From: Jaehoon Chung [mailto:jh80.ch...@samsung.com] > Sent: Friday, November 02, 2012 10:03 AM > To: Huang Changming-R66093 > Cc: Andy Fleming; Lukasz Majewski; Jaehoon Chung; Marek Vasut; u- > b...@lists.denx.de; Wen; l...@theia.denx.de > Subject: Re: [U-Boot] [PATCH] powerpc/esdhc: force the bus width to 4bit > > Hi, > > Andy has sent the patch related with this problem. > Check the patch "[RFC] mmc: Properly determine maximum supported bus > width" > > Best Regards, > Jaehoon Chung > >> decide the best workaround was to cripple our controller by > >> eliminating support for 8-bit? > > I see 12bit width when using mmcinfo, then found out the mmc.c has > > been changed, and I assume this change is right, So I have to force our > controller to just support 4bit width, otherwise, the 12bit bus width is > not correct. > > > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/esdhc: force the bus width to 4bit
Best Regards
Jerry Huang
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Andy Fleming
> Sent: Thursday, November 01, 2012 12:09 PM
> To: Lukasz Majewski
> Cc: Jaehoon Chung; Marek Vasut; Lei Wen; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] powerpc/esdhc: force the bus width to 4bit
>
> >
> > Hmm... looks like it is code done by me :-) So little explanation
> > shall be given.
> >
> > This code is necessary for some targets (like Samsung's Goni) which
> > can only support 4 bit MMC mode.
> >
> >> >>for (; width >= 0; width--) {
> >> >>
> >> >>
> >> >> So for FSL ESDHC, the width = 3, after implement mmc_switch
> >> >> successfully, will set the bus to 4 * width. Therefore, I will get
> >> >> the 12bit (4 x 3) bus width.
> >> This problem is MMC subsystem's bug.
> >> I think good that will modify the code in mmc.c.
> >> If caps is set to MMC_MODE_4BIT | MMC_MODE_8BIT, we can see the 12bit
> >> support with using "mmcinfo" command
> >>
> >
> > The mmc_set_bus_width(mmc, 4 * width) in conjunction to above code
> > causes the problem.
> >
> > I agree, that this code shall be refactored.
> > Lei, what do you think?
>
>
> I am... very confused by this whole thread. And the code associated with
> it. The host_caps field has a bitmask which declares the widths supported
> by a given controller.
>
> What would possess you to index them by addition, and convert their
> values by multiplication?? It's a bitfield! I'm embarrassed that I
> allowed this code in, and will review future submissions from you with a
> very skeptical eye.
>
> Ah, and further review indicates it is Lei Wen who introduced the idea of
> iterating through a bitfield by subtraction, though I can see how
> iterating through the EXT_CSD *field* definition (which looks a lot like
> a bitfield, but may not be) *might* be considered reasonable.
>
> Meanwhile, Huang Changming, why would you see this broken code, and then
> decide the best workaround was to cripple our controller by eliminating
> support for 8-bit?
I see 12bit width when using mmcinfo, then found out the mmc.c has been
changed, and I assume this change is right,
So I have to force our controller to just support 4bit width, otherwise, the
12bit bus width is not correct.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/esdhc: force the bus width to 4bit
> -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Thursday, November 01, 2012 11:06 AM > To: Huang Changming-R66093 > Cc: Andy Fleming; u-b...@linux.freescale.net; u-boot@lists.denx.de > Subject: Re: [PATCH] powerpc/esdhc: force the bus width to 4bit > > Dear Huang Changming-R66093, > > Reposting _AGAIN_ because you again discarded the U-Boot ML address. I don't know why, I replied to all, not discard any address. > > > > -Original Message- > > > From: Marek Vasut [mailto:ma...@denx.de] > > > Sent: Thursday, November 01, 2012 10:26 AM > > > To: Huang Changming-R66093 > > > Cc: Andy Fleming; u-b...@linux.freescale.net > > > Subject: Re: [PATCH] powerpc/esdhc: force the bus width to 4bit > > > > > > Dear Huang Changming-R66093, > > > > > > > Andy, > > > > Do you agree my suggest to revert these codes to fix this issue? > > > > > > Please ... do us all a favor, read [1] and stop being so > > > inconsiderate of others! Given that I can no longer make any sense > > > of this thread because of your top-posting making it complete utmost > > > mess, my opinion is NAK on reverting them. > > > > > > [1] http://www.ietf.org/rfc/rfc1855.txt > > > > Then, could you give some suggest, how to fix the 12bit-width issue? > > see drivers/mmc/mmc.c: > > 1089 width = ((mmc->host_caps & MMC_MODE_MASK_WIDTH_BITS) >> > 1090 MMC_MODE_WIDTH_BITS_SHIFT); > > Fix this snipped of code and the related code below ... that's the way to > go about it. > Yes, I can change these codes to: Width = EXT_CSD_BUS_WIDTH_8; Then, first value of width will be 2. But, those modification is I said, the codes is reverted to the old codes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/esdhc: force the bus width to 4bit
> > > Dear chang-ming.hu...@freescale.com,
> > >
> > > > From: Jerry Huang
> > > >
> > > > For the current u-boot codes, only 4bit/1bit SD/SDHC bus width is
> > >
> > > support.
> > >
> > > > So for MMC card, we also support 4bit bus width, otherwiase, we
> > > > will
> > >
> > > > get the 12bit bus width, which is not correct:
> > > Andy ... can you please explain? I don't quite understand the
> > > problem, I thought we had no problem supporting 8bit mmc (esp. if
> > > the controller handles that for us mostly).
> >
> > Yes, the controller support 8bit MMC.
> >
> > FSL ESDHC driver set the host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT;
> > But, the current codes for MMC card has been changed to:
> >
> > } else {
> > width = ((mmc->host_caps & MMC_MODE_MASK_WIDTH_BITS) >>
> > MMC_MODE_WIDTH_BITS_SHIFT);
> > for (; width >= 0; width--) {
> >
> >
> > So for FSL ESDHC, the width = 3, after implement mmc_switch
> > successfully, will set the bus to 4 * width. Therefore, I will get the
> > 12bit (4 x 3) bus width.
> >
> > Below is the old codes (width = 2):
> > } else {
> > for (width = EXT_CSD_BUS_WIDTH_8; width >= 0; width--)
> > {
> [...]
>
>
> Uh, so it's a bug in the MMC subsystem?
> Best regards,
I don't know. Maybe Andy can give some comment.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/esdhc: force the bus width to 4bit
Best Regards
Jerry Huang
> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Tuesday, October 23, 2012 3:24 PM
> To: Huang Changming-R66093
> Cc: u-boot@lists.denx.de; Andy Fleming
> Subject: Re: [PATCH] powerpc/esdhc: force the bus width to 4bit
>
> Dear chang-ming.hu...@freescale.com,
>
> > From: Jerry Huang
> >
> > For the current u-boot codes, only 4bit/1bit SD/SDHC bus width is
> support.
> > So for MMC card, we also support 4bit bus width, otherwiase, we will
> > get the 12bit bus width, which is not correct:
>
> Andy ... can you please explain? I don't quite understand the problem, I
> thought we had no problem supporting 8bit mmc (esp. if the controller
> handles that for us mostly).
Yes, the controller support 8bit MMC.
FSL ESDHC driver set the host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT;
But, the current codes for MMC card has been changed to:
} else {
width = ((mmc->host_caps & MMC_MODE_MASK_WIDTH_BITS) >>
MMC_MODE_WIDTH_BITS_SHIFT);
for (; width >= 0; width--) {
So for FSL ESDHC, the width = 3, after implement mmc_switch successfully, will
set the bus to 4 * width.
Therefore, I will get the 12bit (4 x 3) bus width.
Below is the old codes (width = 2):
} else {
for (width = EXT_CSD_BUS_WIDTH_8; width >= 0; width--) {
> > => mmcinfo
> > Device: FSL_SDHC
> > Manufacturer ID: 1e
> > OEM:
> > Name: MMC
> > Tran Speed: 5200
> > Rd Block Len: 512
> > MMC version 4.0
> > High Capacity: No
> > Capacity: 1.9 GiB
> > Bus Width: 12-bit
> >
> > Signed-off-by: Jerry Huang
> > CC: Andy Fleming
> > CC: Marek Vasut
> > ---
> > drivers/mmc/fsl_esdhc.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index
> > 3f8d30d..7b83dd2 100644
> > --- a/drivers/mmc/fsl_esdhc.c
> > +++ b/drivers/mmc/fsl_esdhc.c
> > @@ -577,7 +577,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct
> > fsl_esdhc_cfg *cfg) return -1;
> > }
> >
> > - mmc->host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT;
> > + mmc->host_caps = MMC_MODE_4BIT;
> >
> > if (caps & ESDHC_HOSTCAPBLT_HSS)
> > mmc->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
>
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/mpc85xx/p1_p2_rdb: add all LAWs during SPL
This maybe cause the overlap error: powerpc-linux-gnu-ld: section .resetvec loaded at [ff800ffc,ff800fff] overlaps section .data loaded at [ff800ec8,ff80102f] maybe we can think about to remove or modify Kumar's patch: commit 7639675131673e8f1582d760203a9af34fba9e79 Author: Kumar Gala Date: Thu Feb 3 09:02:13 2011 -0600 powerpc/8xxx: Fix LAW init to respect pre-initialized entries If some pre-boot or earlier stage bootloader (NAND SPL) has setup LAW entries consider them good and mark them used. In the NAND SPL case we skip re-initializing based on the law_table since the SPL phase already did that. Signed-off-by: Kumar Gala Best Regards Jerry Huang > -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Scott Wood > Sent: Friday, August 10, 2012 12:52 AM > To: McClintock Matthew-B29882 > Cc: Wood Scott-B07421; Kumar Gala; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH 2/2] powerpc/mpc85xx/p1_p2_rdb: add all LAWs > during SPL > > On 08/08/2012 09:28 PM, McClintock Matthew-B29882 wrote: > > On Wed, Aug 8, 2012 at 9:27 PM, Matthew McClintock > wrote: > >> On Wed, Aug 8, 2012 at 8:06 PM, Scott Wood > wrote: > >>> LAW init is skipped in the SPL payload because it's assumed that the > >>> SPL has taken care of it -- so make sure the SPL loads all the LAWs > >>> as is done on other boards. > >> > >> It might be good to try this on a few different compilers to see if > >> they are all under the size requirement. I've made this smaller from > >> other work so it could still be OK. > > I don't have "a few different compilers" handy to test with -- and even > if I did, it wouldn't be exhaustive. This fixes a bug. If someone finds > that they can't build with some other compiler, they can report the bug > and we'll deal with it. > > > Err, I spoke too soon... this might not be upstreamed though. > > Why not? > > -Scott > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] SDHC/MMC: fix the wrong infomation after change SD card
Hi, Andy Could you give some reason why eMMC device will be so slowed down by re-initialization? I think eMMC device is initialized only once, except it invoke 'mmc_init' many times. The workaround "mmc rescan" works when replace the card. But if one card is removed, then use "mmcfinfo": there is no card present, while the previous card information is displayed, I don't' think it make sense. => mmc rescan MMC: no card present => mmcinfo MMC: no card present Device: FSL_SDHC Manufacturer ID: 2 OEM: 544d Name: SD04G Tran Speed: 5000 Rd Block Len: 512 SD version 2.0 High Capacity: Yes Capacity: 3.7 GiB Bus Width: 4-bit Best Regards Jerry Huang > -Original Message- > From: Andy Fleming [mailto:aflem...@gmail.com] > Sent: Saturday, July 14, 2012 5:33 AM > To: Huang Changming-R66093 > Cc: u-boot@lists.denx.de; Marek Vasut > Subject: Re: [PATCH 1/2 v2] SDHC/MMC: fix the wrong infomation after > change SD card > > On Wed, Jul 11, 2012 at 4:29 AM, Huang Changming-R66093 > wrote: > > Hi, Andy, > > There is not any feedback for very long time, > > Could it be applied to the u-boot? > > > I'm afraid I have to reject this patch. We need to find a better > solution to the two problems: > > 1) We want to change cards and still have mmc commands work > 2) We don't want eMMC devices to be slowed down by constantly > re-initializing their cards. > > Normally, I would err on the side of #1, but there's a simple > workaround. If you replace the card, execute "mmc rescan", and the > card will be reinitialized. Please let me know if that workaround > doesn't work. I hope, in the future, we'll have some code which makes > both possible, by being able to detect that a card has been changed, > but for now I think the current system is reasonably satisfactory to > both cases #1 and #2. > > Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v3] FSL/eSDHC: enable the clock to detect the SD card
Hi, Andy There is not any feedback for very long time, Could it be applied to u-boot? Best Regards Jerry Huang > -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Huang Changming-R66093 > Sent: Monday, May 21, 2012 10:35 AM > To: Wood Scott-B07421 > Cc: Marek Vasut; u-boot@lists.denx.de; Andy Fleming > Subject: Re: [U-Boot] [PATCH 2/2 v3] FSL/eSDHC: enable the clock to > detect the SD card > > > > Best Regards > Jerry Huang > > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Friday, May 18, 2012 11:55 PM > > To: Huang Changming-R66093 > > Cc: u-boot@lists.denx.de; Marek Vasut; Andy Fleming > > Subject: Re: [U-Boot] [PATCH 2/2 v3] FSL/eSDHC: enable the clock to > > detect the SD card > > > > On 05/18/2012 04:57 AM, chang-ming.hu...@freescale.com wrote: > > > From: Jerry Huang > > > > > > For FSL low-end processors (VVN2.2), in order to detect the SD card, > > > we should enable PEREN, HCKEN and IPGEN to enable the clock. > > > Otherwise, after booting the u-boot, and then inserting the SD card, > > > the SD card can't be detected. > > > For SDHC VVN2.3 IP, these bits are reserved, and SDCLKEN is used. > > > And when accessing to these reserved bit, no any impact happened. > > > > Again, have you talked to a hardware designer and confirmed that > > there's no impact from setting these bits on chips where they're > > reserved? Just because you don't notice any obvious impact doesn't > > mean it's totally safe. > > > Do you read the FSL SDHC driver? If not, please read it first. > Without my this patch, FSL SDHC driver has done it as I mentioned. > The committer provided the patch to support VVN2.3 should talk to the > hardware designer, And he think it is safe. Otherwise he should detect > the VVN to do the different thing. > The below is the code driver enable these bit: > In function set_sysctl: > clk = SYSCTL_PEREN | SYSCTL_CKEN; > in function esdhc_init: > esdhc_write32(®s->sysctl, SYSCTL_HCKEN | SYSCTL_IPGEN); > > My work is just to pick up the codes from the driver and do it again in > function fsl_esdhc_initialize: > esdhc_setbits32(®s->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN > | SYSCTL_IPGEN | SYSCTL_CKEN); > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] SDHC/MMC: fix the wrong infomation after change SD card
Hi, Andy,
There is not any feedback for very long time,
Could it be applied to the u-boot?
Best Regards
Jerry Huang
> -Original Message-
> From: Huang Changming-R66093
> Sent: Friday, May 18, 2012 5:57 PM
> To: u-boot@lists.denx.de
> Cc: Huang Changming-R66093; Andy Fleming; Marek Vasut
> Subject: [PATCH 1/2 v2] SDHC/MMC: fix the wrong infomation after change
> SD card
>
> From: Jerry Huang
>
> When first inserting the SD card to slot, the command "mmcinfo" can
> display the card information correctly.
> But, then removing the SD card or inserting another SD card to slot,
> the command "mmcinfo" can't display the information correctly.
>
> when we use command "mmcinfo" every time, the driver must initialize the
> SD card again, instead of assuming the card has been initialized.
>
> Therefore remove the detect codes from mmc_init function.
> And add the codes to check the mmc_init, only when mmc_init return
> the right value, driver will print the information.
>
> Below is the error log (SD card removed):
> => mmcinfo
> MMC: no card present
> Device: FSL_SDHC
> Manufacturer ID: 3
> OEM: 5344
> Name: SD02G
> Tran Speed: 2500
> Rd Block Len: 512
> SD version 2.0
> High Capacity: No
> Capacity: 1.8 GiB
> Bus Width: 4-bit
>
> Signed-off-by: Jerry Huang
> CC: Andy Fleming
> CC: Marek Vasut
> ---
> changes for v2:
> - keep the member has_init
> - only remove the detect code
>
> common/cmd_mmc.c |5 ++---
> drivers/mmc/mmc.c |3 ---
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
> index 750509d..e73ce03 100644
> --- a/common/cmd_mmc.c
> +++ b/common/cmd_mmc.c
> @@ -131,9 +131,8 @@ int do_mmcinfo (cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> mmc = find_mmc_device(curr_device);
>
> if (mmc) {
> - mmc_init(mmc);
> -
> - print_mmcinfo(mmc);
> + if (!mmc_init(mmc))
> + print_mmcinfo(mmc);
> return 0;
> } else {
> printf("no mmc device at slot %x\n", curr_device);
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index f92b662..af644bb 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1323,9 +1323,6 @@ int mmc_init(struct mmc *mmc)
> return NO_CARD_ERR;
> }
>
> - if (mmc->has_init)
> - return 0;
> -
> err = mmc->init(mmc);
>
> if (err)
> --
> 1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] SD/MMC: check the card status during erase operation
Hi, Andy, There is not any feedback for very long time. Could it be applied to u-boot? Best Regards Jerry Huang > -Original Message- > From: Huang Changming-R66093 > Sent: Friday, May 18, 2012 5:01 PM > To: u-boot@lists.denx.de > Cc: Huang Changming-R66093; Andy Fleming; Marek Vasut > Subject: [PATCH] SD/MMC: check the card status during erase operation > > From: Jerry Huang > > Use the function 'mmc_send_status' to check the card status. > only when the card is ready, driver can send the next erase command > to the card, otherwise, the erase will failed: > => mmc erase 0 1 > MMC erase: dev # 0, block # 0, count 1 ... 1 blocks erase: OK > => mmc erase 0 2 > MMC erase: dev # 0, block # 0, count 2 ... mmc erase failed > 1 blocks erase: ERROR > => mmc erase 0 4 > MMC erase: dev # 0, block # 0, count 4 ... mmc erase failed > 1 blocks erase: ERROR > > Signed-off-by: Jerry Huang > CC: Andy Fleming > CC: Marek Vasut > --- > drivers/mmc/mmc.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c > index 596732e..f92b662 100644 > --- a/drivers/mmc/mmc.c > +++ b/drivers/mmc/mmc.c > @@ -333,6 +333,7 @@ mmc_berase(int dev_num, unsigned long start, lbaint_t > blkcnt) > int err = 0; > struct mmc *mmc = find_mmc_device(dev_num); > lbaint_t blk = 0, blk_r = 0; > + int timeout = 1000; > > if (!mmc) > return -1; > @@ -352,6 +353,10 @@ mmc_berase(int dev_num, unsigned long start, > lbaint_t blkcnt) > break; > > blk += blk_r; > + > + /* Waiting for the ready status */ > + if (mmc_send_status(mmc, timeout)) > + return 0; > } > > return blk; > -- > 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v3] FSL/eSDHC: enable the clock to detect the SD card
VVN2.2/VVN2.3 is the vendor version number, that is the FSL SDHC IP verion. Best Regards Jerry Huang > -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Saturday, May 19, 2012 12:03 AM > To: Huang Changming-R66093 > Cc: u-boot@lists.denx.de; Andy Fleming > Subject: Re: [PATCH 2/2 v3] FSL/eSDHC: enable the clock to detect the SD > card > > Dear chang-ming.hu...@freescale.com, > > > From: Jerry Huang > > > > For FSL low-end processors (VVN2.2) > > What's VVN2.2 ? > > > , in order to detect the SD card, > > we should enable PEREN, HCKEN and IPGEN to enable the clock. > > Otherwise, after booting the u-boot, and then inserting the SD card, > > the SD card can't be detected. > > For SDHC VVN2.3 IP > > VVN2.3 ? > > > , these bits are reserved, and SDCLKEN is used. > > And when accessing to these reserved bit, no any impact happened. > > > > Signed-off-by: Jerry Huang > > CC: Andy Fleming > > CC: Marek Vasut > > --- > > changes for v2: > > - correct the typo > > changes for v3: > > - enable all clock bits for VVN2.3 and VVN2.2 > > - use funciton esdhc_setbits32 > > - tested on p1022ds, p1025rdb, p1020mbg-pc, mpc8536ds, p3041ds > > > > drivers/mmc/fsl_esdhc.c |3 +++ > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index > > a2f35e3..930a5c5 100644 > > --- a/drivers/mmc/fsl_esdhc.c > > +++ b/drivers/mmc/fsl_esdhc.c > > @@ -491,6 +491,9 @@ int fsl_esdhc_initialize(bd_t *bis, struct > > fsl_esdhc_cfg *cfg) /* First reset the eSDHC controller */ > > esdhc_reset(regs); > > > > + esdhc_setbits32(®s->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN > > + | SYSCTL_IPGEN | SYSCTL_CKEN); > > + > > mmc->priv = cfg; > > mmc->send_cmd = esdhc_send_cmd; > > mmc->set_ios = esdhc_set_ios; > > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v3] FSL/eSDHC: enable the clock to detect the SD card
Best Regards Jerry Huang > -Original Message- > From: Wood Scott-B07421 > Sent: Friday, May 18, 2012 11:55 PM > To: Huang Changming-R66093 > Cc: u-boot@lists.denx.de; Marek Vasut; Andy Fleming > Subject: Re: [U-Boot] [PATCH 2/2 v3] FSL/eSDHC: enable the clock to > detect the SD card > > On 05/18/2012 04:57 AM, chang-ming.hu...@freescale.com wrote: > > From: Jerry Huang > > > > For FSL low-end processors (VVN2.2), in order to detect the SD card, > > we should enable PEREN, HCKEN and IPGEN to enable the clock. > > Otherwise, after booting the u-boot, and then inserting the SD card, > > the SD card can't be detected. > > For SDHC VVN2.3 IP, these bits are reserved, and SDCLKEN is used. > > And when accessing to these reserved bit, no any impact happened. > > Again, have you talked to a hardware designer and confirmed that there's > no impact from setting these bits on chips where they're reserved? Just > because you don't notice any obvious impact doesn't mean it's totally > safe. > Do you read the FSL SDHC driver? If not, please read it first. Without my this patch, FSL SDHC driver has done it as I mentioned. The committer provided the patch to support VVN2.3 should talk to the hardware designer, And he think it is safe. Otherwise he should detect the VVN to do the different thing. The below is the code driver enable these bit: In function set_sysctl: clk = SYSCTL_PEREN | SYSCTL_CKEN; in function esdhc_init: esdhc_write32(®s->sysctl, SYSCTL_HCKEN | SYSCTL_IPGEN); My work is just to pick up the codes from the driver and do it again in function fsl_esdhc_initialize: esdhc_setbits32(®s->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN | SYSCTL_IPGEN | SYSCTL_CKEN); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] SDHC/MMC: remove the member has_init
If some peoples rely on this function, then we need to remove the below codes
from 'mmc_init':
if (mmc->has_init)
return 0;
when we use command "mmcinfo" every time, the driver must initialize the SD
card again,
instead of assuming the card has been initialized.
Best Regards
Jerry Huang
> -Original Message-
> From: Andy Fleming [mailto:aflem...@gmail.com]
> Sent: Wednesday, May 09, 2012 6:17 AM
> To: Huang Changming-R66093
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH 2/2] SDHC/MMC: remove the member has_init
>
> I am highly inclined to apply this patch, as it was originally the
> intent that the init function get called every time. If it doesn't,
> it's impossible to deal with cards being inserted and removed after
> U-Boot comes up.
>
> However, I've seen some recent chatter on the list where it sounds
> like people are relying on this functionality, now. So we need some
> discussion. Assuming I don't apply this patch, how do we deal with the
> problem of cards being removed or inserted after U-Boot boots?
>
> On Tue, Mar 27, 2012 at 5:25 AM, wrote:
> > From: Jerry Huang
> >
> > When first inserting the SD card to slot, the command "mmcinfo" can
> > display the card information correctly.
> > But, then removing the SD card or inserting another SD card to slot,
> > the command "mmcinfo" can't display the information correctly.
> >
> > Therefore remove this member 'has_init' from 'structure mmc',
> > and add the codes to check the mmc_init, only when mmc_init return
> > the right value, driver will print the information.
> >
> > Below is the error log SD card removed:
> > => mmcinfo
> > MMC: no card present
> > Device: FSL_SDHC
> > Manufacturer ID: 3
> > OEM: 5344
> > Name: SD02G
> > Tran Speed: 2500
> > Rd Block Len: 512
> > SD version 2.0
> > High Capacity: No
> > Capacity: 1.8 GiB
> > Bus Width: 4-bit
> >
> > Signed-off-by: Jerry Huang
> > CC: Andy Fleming
> > ---
> > common/cmd_mmc.c | 7 ++-
> > drivers/mmc/mmc.c | 9 +
> > include/mmc.h | 1 -
> > 3 files changed, 3 insertions(+), 14 deletions(-)
> >
> > diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
> > index 8f13c22..382ea4e 100644
> > --- a/common/cmd_mmc.c
> > +++ b/common/cmd_mmc.c
> > @@ -131,9 +131,8 @@ int do_mmcinfo (cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> > mmc = find_mmc_device(curr_device);
> >
> > if (mmc) {
> > - mmc_init(mmc);
> > -
> > - print_mmcinfo(mmc);
> > + if (!mmc_init(mmc))
> > + print_mmcinfo(mmc);
> > return 0;
> > } else {
> > printf("no mmc device at slot %x\n", curr_device);
> > @@ -172,8 +171,6 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> > return 1;
> > }
> >
> > - mmc->has_init = 0;
> > -
> > if (mmc_init(mmc))
> > return 1;
> > else
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index 9055b01..ad0ebc3 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -1235,14 +1235,10 @@ int mmc_init(struct mmc *mmc)
> > int err;
> >
> > if (mmc_getcd(mmc) == 0) {
> > - mmc->has_init = 0;
> > printf("MMC: no card present\n");
> > return NO_CARD_ERR;
> > }
> >
> > - if (mmc->has_init)
> > - return 0;
> > -
> > err = mmc->init(mmc);
> >
> > if (err)
> > @@ -1277,10 +1273,7 @@ int mmc_init(struct mmc *mmc)
> > }
> >
> > err = mmc_startup(mmc);
> > - if (err)
> > - mmc->has_init = 0;
> > - else
> > - mmc->has_init = 1;
> > +
> > return err;
> > }
> >
> > diff --git a/include/mmc.h b/include/mmc.h
> > index 8744604..8e37504 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -277,7 +277,6 @@ struct mmc {
> > void *priv;
> > uint voltages;
> > uint version;
> > - uint has_init;
> > uint f_min;
> > uint f_max;
> > int high_capacity;
> > --
> > 1.7.5.4
> >
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] FSL/eSDHC: enable the peripheral clock to detect the card
Hi, Do you have any comment about this patch? It can be merged into next version? Best Regards Jerry Huang > -Original Message- > From: Huang Changming-R66093 > Sent: Thursday, March 29, 2012 10:11 AM > To: u-boot@lists.denx.de > Cc: Huang Changming-R66093; Andy Fleming > Subject: [PATCH 1/2 v2] FSL/eSDHC: enable the peripheral clock to detect > the card > > From: Jerry Huang > > According to the card detection of p1/p2 platform RM, > we should set SYSCTL[PEREN] to enable the clock. > Otherwise, after booting the u-boot, and then inserting the SD card, > the SD card can't be detected. > > Signed-off-by: Jerry Huang > CC: Andy Fleming > --- > changes for v2: > - correct the typo > > drivers/mmc/fsl_esdhc.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c > index a2f35e3..1682a79 100644 > --- a/drivers/mmc/fsl_esdhc.c > +++ b/drivers/mmc/fsl_esdhc.c > @@ -491,6 +491,8 @@ int fsl_esdhc_initialize(bd_t *bis, struct > fsl_esdhc_cfg *cfg) > /* First reset the eSDHC controller */ > esdhc_reset(regs); > > + esdhc_write32(®s->sysctl, SYSCTL_PEREN); > + > mmc->priv = cfg; > mmc->send_cmd = esdhc_send_cmd; > mmc->set_ios = esdhc_set_ios; > -- > 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] SDHC/MMC: remove the member has_init
Hi,
Do you have any comment about this patch?
It can be merge into the next version?
Best Regards
Jerry Huang
> -Original Message-
> From: Huang Changming-R66093
> Sent: Tuesday, March 27, 2012 6:25 PM
> To: u-boot@lists.denx.de
> Cc: Huang Changming-R66093; Andy Fleming
> Subject: [PATCH 2/2] SDHC/MMC: remove the member has_init
>
> From: Jerry Huang
>
> When first inserting the SD card to slot, the command "mmcinfo" can
> display the card information correctly.
> But, then removing the SD card or inserting another SD card to slot,
> the command "mmcinfo" can't display the information correctly.
>
> Therefore remove this member 'has_init' from 'structure mmc',
> and add the codes to check the mmc_init, only when mmc_init return
> the right value, driver will print the information.
>
> Below is the error log SD card removed:
> => mmcinfo
> MMC: no card present
> Device: FSL_SDHC
> Manufacturer ID: 3
> OEM: 5344
> Name: SD02G
> Tran Speed: 2500
> Rd Block Len: 512
> SD version 2.0
> High Capacity: No
> Capacity: 1.8 GiB
> Bus Width: 4-bit
>
> Signed-off-by: Jerry Huang
> CC: Andy Fleming
> ---
> common/cmd_mmc.c |7 ++-
> drivers/mmc/mmc.c |9 +
> include/mmc.h |1 -
> 3 files changed, 3 insertions(+), 14 deletions(-)
>
> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
> index 8f13c22..382ea4e 100644
> --- a/common/cmd_mmc.c
> +++ b/common/cmd_mmc.c
> @@ -131,9 +131,8 @@ int do_mmcinfo (cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> mmc = find_mmc_device(curr_device);
>
> if (mmc) {
> - mmc_init(mmc);
> -
> - print_mmcinfo(mmc);
> + if (!mmc_init(mmc))
> + print_mmcinfo(mmc);
> return 0;
> } else {
> printf("no mmc device at slot %x\n", curr_device);
> @@ -172,8 +171,6 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> return 1;
> }
>
> - mmc->has_init = 0;
> -
> if (mmc_init(mmc))
> return 1;
> else
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 9055b01..ad0ebc3 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1235,14 +1235,10 @@ int mmc_init(struct mmc *mmc)
> int err;
>
> if (mmc_getcd(mmc) == 0) {
> - mmc->has_init = 0;
> printf("MMC: no card present\n");
> return NO_CARD_ERR;
> }
>
> - if (mmc->has_init)
> - return 0;
> -
> err = mmc->init(mmc);
>
> if (err)
> @@ -1277,10 +1273,7 @@ int mmc_init(struct mmc *mmc)
> }
>
> err = mmc_startup(mmc);
> - if (err)
> - mmc->has_init = 0;
> - else
> - mmc->has_init = 1;
> +
> return err;
> }
>
> diff --git a/include/mmc.h b/include/mmc.h
> index 8744604..8e37504 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -277,7 +277,6 @@ struct mmc {
> void *priv;
> uint voltages;
> uint version;
> - uint has_init;
> uint f_min;
> uint f_max;
> int high_capacity;
> --
> 1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] FSL/eSDHC: enable the peripheral clock to detect the card
Thanks Jerry Huang > -Original Message- > From: Stefano Babic [mailto:sba...@denx.de] > Sent: Wednesday, March 28, 2012 1:17 AM > To: Dirk Behme > Cc: Huang Changming-R66093; u-boot@lists.denx.de; Andy Fleming > Subject: Re: [U-Boot] [PATCH 1/2] FSL/eSDHC: enable the peripheral clock > to detect the card > > On 27/03/2012 13:01, Dirk Behme wrote: > > On 27.03.2012 12:25, chang-ming.hu...@freescale.com wrote: > >> From: Jerry Huang > >> > >> According to the card detection of p1/p2 paltform RM, > > > > typo => platform > > > >> we should set SYSCTL[PEREN] to enable the clock. > >> Otherwise, after booting the u-boot, and then inserting the SD card, > >> the SD card can't be detected. > >> > >> Signed-off-by: Jerry Huang > >> CC: Andy Fleming > >> --- > >> drivers/mmc/fsl_esdhc.c |2 ++ > >> 1 files changed, 2 insertions(+), 0 deletions(-) > >> > >> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index > >> a2f35e3..1682a79 100644 > >> --- a/drivers/mmc/fsl_esdhc.c > >> +++ b/drivers/mmc/fsl_esdhc.c > >> @@ -491,6 +491,8 @@ int fsl_esdhc_initialize(bd_t *bis, struct > >> fsl_esdhc_cfg *cfg) > >> /* First reset the eSDHC controller */ > >> esdhc_reset(regs); > >> > >> +esdhc_write32(®s->sysctl, SYSCTL_PEREN); > > > > If I read the iMX6 manual correctly, the SYSCTL_PEREN isn't > > implemented there. > > In the copy I could put my hands, SYSCTL_PEREN is implemented for i.MX6. > However, I do not know if this has an influence. ESDHC should be clocked > with SDCLKEN, that is enabled by default on i.MX (both MX5 and MX6). > > > So this should be a NOP for iMX6? > > However, if it is not implemented and it is marked as reserved, we should > not set it. > I.MX6/5 reuse the fsl_esdhc.c driver, and he don't care these reserved field. Otherwise he should change this driver. E.g: In function esdhc_init: esdhc_write32(®s->sysctl, SYSCTL_HCKEN | SYSCTL_IPGEN); in function set_sysctl: clk = SYSCTL_PEREN | SYSCTL_CKEN; esdhc_setbits32(®s->sysctl, clk); so I think my code has no any problem. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] FSL/eSDHC: enable the peripheral clock to detect the card
Thanks Jerry Huang > -Original Message- > From: Stefano Babic [mailto:sba...@denx.de] > Sent: Wednesday, March 28, 2012 1:13 AM > To: Huang Changming-R66093 > Cc: u-boot@lists.denx.de; Andy Fleming > Subject: Re: [U-Boot] [PATCH 1/2] FSL/eSDHC: enable the peripheral clock > to detect the card > > On 27/03/2012 12:25, chang-ming.hu...@freescale.com wrote: > > From: Jerry Huang > > > > According to the card detection of p1/p2 paltform RM, we should set > > SYSCTL[PEREN] to enable the clock. > > Otherwise, after booting the u-boot, and then inserting the SD card, > > the SD card can't be detected. > > > > Signed-off-by: Jerry Huang > > CC: Andy Fleming > > --- > > Hi Jerry, > > > drivers/mmc/fsl_esdhc.c |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index > > a2f35e3..1682a79 100644 > > --- a/drivers/mmc/fsl_esdhc.c > > +++ b/drivers/mmc/fsl_esdhc.c > > @@ -491,6 +491,8 @@ int fsl_esdhc_initialize(bd_t *bis, struct > fsl_esdhc_cfg *cfg) > > /* First reset the eSDHC controller */ > > esdhc_reset(regs); > > > > + esdhc_write32(®s->sysctl, SYSCTL_PEREN); > > + > > You add this setup to all architectures: PQIII, i.MX5, i.MX6. Is it what > you really want ? In fact, this field is set in function 'set_sysctl', too. In order to detect the card, I just reset it in initialize stage. For p1/p2, the field SYSCTL[PEREN](bit29) is needed to enable the peripheral clock before Detecting the SD card. For p3041, this field is reserved, I think I.MX5 and I.MX6 has the same setting. And I have tested this field on p3041, accessing this field has no any impact for SD controller. In fact, you can find out, the driver fsl_esdh.c is first wrote for p1/p2 (has PEREN/KCKEN/IPGEN, bit29/30/31), i.MXx/PQIII just reuses it, and some registers have difference setting, such as SYSCRL[29, 30, 31] for p1/p2, they are reserved for p3041. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] powerpc/mpc83xx: set TXEQA/TXEQE value for mpc837XE sata
Hi, Kim Do you have any comment on this patch? > -Original Message- > From: Huang Changming-R66093 > Sent: Thursday, November 17, 2011 10:16 AM > To: u-boot@lists.denx.de > Cc: Huang Changming-R66093; Phillips Kim-R1AAHA > Subject: [PATCH v2] powerpc/mpc83xx: set TXEQA/TXEQE value for mpc837XE > sata > > From: Jerry Huang > > In the current u-boot code, the value of these fields are the reserved > value (0b100), through the signal integrity measurement on freescale's > board with these reserved setting, the signal eye is out of the > recommended > spec for non-transition amplitude at 500mV nominal. > According to the errata for MPC8379E, we should make a change to the > recommended setting from essentially nothing at this time to 0b001 for > SATA. > > Signed-off-by: Jerry Huang > CC: Kim Phillips > --- > changes for v2: > - use clrsetbits_be32 to clear and set the value > > arch/powerpc/cpu/mpc83xx/serdes.c | 11 ++- > 1 files changed, 10 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/cpu/mpc83xx/serdes.c > b/arch/powerpc/cpu/mpc83xx/serdes.c > index fecfc80..a88fab9 100644 > --- a/arch/powerpc/cpu/mpc83xx/serdes.c > +++ b/arch/powerpc/cpu/mpc83xx/serdes.c > @@ -1,7 +1,7 @@ > /* > * Freescale SerDes initialization routine > * > - * Copyright (C) 2007 Freescale Semicondutor, Inc. > + * Copyright (C) 2007,2011 Freescale Semicondutor, Inc. > * Copyright (C) 2008 MontaVista Software, Inc. > * > * Author: Li Yang > @@ -20,6 +20,10 @@ > /* SerDes registers */ > #define FSL_SRDSCR0_OFFS 0x0 > #define FSL_SRDSCR0_DPP_1V2 0x8800 > +#define FSL_SRDSCR0_TXEQA_MASK 0x7000 > +#define FSL_SRDSCR0_TXEQA_SATA 0x1000 > +#define FSL_SRDSCR0_TXEQE_MASK 0x0700 > +#define FSL_SRDSCR0_TXEQE_SATA 0x0100 > #define FSL_SRDSCR1_OFFS 0x4 > #define FSL_SRDSCR1_PLLBW0x0040 > #define FSL_SRDSCR2_OFFS 0x8 > @@ -71,6 +75,11 @@ void fsl_setup_serdes(u32 offset, char proto, u32 > rfcks, char vdd) > tmp &= ~FSL_SRDSRSTCTL_SATA_RESET; > out_be32(regs + FSL_SRDSRSTCTL_OFFS, tmp); > > + /* Configure SRDSCR0 */ > + clrsetbits_be32(regs + FSL_SRDSCR0_OFFS, > + FSL_SRDSCR0_TXEQA_MASK | FSL_SRDSCR0_TXEQE_MASK, > + FSL_SRDSCR0_TXEQA_SATA | FSL_SRDSCR0_TXEQE_SATA); > + > /* Configure SRDSCR1 */ > tmp = in_be32(regs + FSL_SRDSCR1_OFFS); > tmp &= ~FSL_SRDSCR1_PLLBW; > -- > 1.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc83xx: set TXEQA/TXEQE value for mpc837XE sata
Thanks and Best Regards Jerry Huang >-Original Message- >From: Phillips Kim-R1AAHA >Sent: Wednesday, November 16, 2011 5:13 PM >To: Huang Changming-R66093 >Cc: u-boot@lists.denx.de >Subject: Re: [PATCH] powerpc/mpc83xx: set TXEQA/TXEQE value for mpc837XE >sata > >On Wed, 16 Nov 2011 15:36:25 +0800 > wrote: > >> From: Jerry Huang >> >> In the current u-boot code, the value of these fields are the reserved >> value (0b100), through the signal integrity measurement on freescale's >> board with these reserved setting, the signal eye is out of the >> recommended spec for non-transition amplitude at 500mV nominal. >> According to the errata for MPC8379E, we should make a change to the >> recommended setting from essentially nothing at this time to 0b001 for >SATA. > >what erratum #? How am I supposed to know this won't break the 8308 >boards that share this file? No erratum number, but you can find the description in "Errata to MPC8379E(Rev1.2 04/2011)" The Serdes of MPC8303 only support PCIe and there is no SATA controller, so it won't break the 8308. >> +/* Configure SRDSCR0 */ >> +tmp = in_be32(regs + FSL_SRDSCR0_OFFS); >> +tmp &= ~FSL_SRDSCR0_TXEQA_MASK; >> +tmp |= FSL_SRDSCR0_TXEQA_SATA; >> +tmp &= ~FSL_SRDSCR0_TXEQE_MASK; >> +tmp |= FSL_SRDSCR0_TXEQE_SATA; >> +out_be32(regs + FSL_SRDSCR0_OFFS, tmp); >> + > >use clrsetbits_be32 > >Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] powerpc/mpc85xx: Set SYSCLK to the required frequency
Kumar and Andy,
This patch has been posted six days, and there is no any feedback.
Could you please give some comment or feedback?
Thanks and Best Regards
Jerry Huang
> -Original Message-
> From: Huang Changming-R66093
> Sent: Thursday, November 03, 2011 3:18 PM
> To: u-boot@lists.denx.de
> Cc: Huang Changming-R66093; Gala Kumar-B11780
> Subject: [PATCH v2] powerpc/mpc85xx: Set SYSCLK to the required
> frequency
>
> From: Jerry Huang
>
> For ICS307-02, there is one general expression to generate SYSCLK:
> CLK1Frequency = InputFrequency * 2 * (VDW + 8) / ((RDW + 2) * OD)
>
> If we want the required frequency for SYSCLK, we must find one solution
> to generate this frequency, this solution includes VDW, RDW and OD.
> For OD, there are only eight option value: 10, 2, 8, 4, 5, 7, 3, 6.
> For RDW, the range is 1 to 127.
> For VDW, the range is 4 to 511.
>
> First, we use one OD, RDW and required SYSCLK to calculate the VDW,
> if VDW is in it's range, we will calculate the CLK1Frequency with
> the OD, RDW and VDW calculated, and we will check this percent
> (CLK1Frequency / required SYSCLK), and the precision is 1/1000.
> if the percent is less than 1/1000, we think the CLK1Frequency is we
> want.
> Otherwise, We will continue to calculate it with the next OD and RDW.
>
> Signed-off-by: Jerry Huang
> CC: Kumar Gala
> ---
> changes for v2:
> - move these macro to .c file
> - change the subject to powerpc/mpc85xx
> - add CC
>
> board/freescale/common/ics307_clk.c | 69
> +++
> board/freescale/common/ics307_clk.h |4 ++-
> board/freescale/common/ngpixis.c| 27 ++
> 3 files changed, 99 insertions(+), 1 deletions(-)
>
> diff --git a/board/freescale/common/ics307_clk.c
> b/board/freescale/common/ics307_clk.c
> index 89d8810..6804a32 100644
> --- a/board/freescale/common/ics307_clk.c
> +++ b/board/freescale/common/ics307_clk.c
> @@ -31,12 +31,81 @@
> #include "pixis.h"
> #endif
>
> +/* define for SYS CLK or CLK1Frequency */
> +#define TTL 1
> +#define CLK2 0
> +#define CRYSTAL 0
> +#define MAX_VDW (511 + 8)
> +#define MAX_RDW (127 + 2)
> +#define MIN_VDW (4 + 8)
> +#define MIN_RDW (1 + 2)
> +#define NUM_OD_SETTING 8
> +/*
> + * These defines cover the industrial temperature range part,
> + * for commercial, change below to 40 and 55000, respectively
> + */
> +#define MAX_VCO 36
> +#define MIN_VCO 6
> +
> /* decode S[0-2] to Output Divider (OD) */
> static u8 ics307_s_to_od[] = {
> 10, 2, 8, 4, 5, 7, 3, 6
> };
>
> /*
> + * Find one solution to generate required frequency for SYSCLK
> + * out_freq: KHz, required frequency to the SYSCLK
> + * the result will be retuned with component RDW, VDW, OD, TTL,
> + * CLK2 and crystal
> + */
> +unsigned long ics307_sysclk_calculator(unsigned long out_freq)
> +{
> + const unsigned long input_freq = CONFIG_ICS307_REFCLK_HZ;
> + unsigned long vdw, rdw, odp, s_vdw, s_rdw, s_odp, od;
> + unsigned long tmp_out, diff, result = 0;
> + int found = 0;
> +
> + for (odp = 0; odp < NUM_OD_SETTING; odp++) {
> + od = ics307_s_to_od[odp];
> + if (od * out_freq < MIN_VCO || od * out_freq > MAX_VCO)
> + continue;
> + for (rdw = MIN_RDW; rdw <= MAX_RDW; rdw++) {
> + /* Calculate the VDW */
> + vdw = out_freq * 1000 * od * rdw / (input_freq * 2);
> + if (vdw > MAX_VDW)
> + vdw = MAX_VDW;
> + if (vdw < MIN_VDW)
> + continue;
> + /* Calculate the temp out frequency */
> + tmp_out = input_freq * 2 * vdw / (rdw * od * 1000);
> + diff = MAX(out_freq, tmp_out) - MIN(out_freq,
> tmp_out);
> + /*
> + * calculate the percent, the precision is 1/1000
> + * If greater than 1/1000, continue
> + * otherwise, we think the solution is we required
> + */
> + if (diff * 1000 / out_freq > 1)
> + continue;
> + else {
> + s_vdw = vdw;
> + s_rdw = rdw;
> + s_odp = odp;
> + found = 1;
> + break;
> + }
> + }
>
Re: [U-Boot] [PATCH v5] MPC8360EMDS: 512MB DDR and 33.33MHz oscillator support
Thanks and Best Regards Jerry Huang > -Original Message- > From: Phillips Kim-R1AAHA > Sent: Thursday, November 03, 2011 4:37 AM > To: McClintock Matthew-B29882 > Cc: Huang Changming-R66093; Tabi Timur-B04825; u-boot@lists.denx.de; > Phillips Kim-R1AAHA > Subject: Re: [U-Boot] [PATCH v5] MPC8360EMDS: 512MB DDR and 33.33MHz > oscillator support > > On Wed, 2 Nov 2011 09:52:17 -0500 > McClintock Matthew-B29882 wrote: > > > On Wed, Nov 2, 2011 at 2:34 AM, Huang Changming-R66093 > > wrote: > > >> > How can I deal with the new board and old board? > > >> > > >> Check the board revision at runtime. > > >> > > > Board Specification says, there is one EEPROM to contain all board > history, and I found it: > > > On I2C2 bus, there is one EEPROM BRD(0x50) from the schematics, but > the content of this EEPROM is 0xff. > > > That's to say, we can't check the board information from this > EEPROM. > > > From the code of mpc8360emds platform, there is not the interface > to check the board information. > > > > > > So, there is no way to check the board revision at runtime. > > Board revision information should be in BCSR12. I'm curious whether > yours contains a higher board revision level than mine: > > => md.b f800 e > f800: 04 04 00 c6 94 60 00 00 ac 2e 00 b8 10 3f.`...? > BCSR12->^^ My board BCSR info: => md.b f800 e f800: 0a 04 00 8f 94 60 00 00 ac 2e 00 b8 22 3f.`.."? > because the sticker on the FPGA says "BCSR 2.1" vs. the "1.0" > encoding above. Best case explanation would be the h/w encoding is 0- > based and they don't bother to update the minor revision number... > > > Is your board special? Maybe the ones customers get go through the > > proper process to have EEPROM updated? Otherwise, you will probably > > need to create a new board type: > > > > $ make mpc8360emds_newmodifier > > wrt setting CONFIG_83XX_CLKIN, it's a little harder to do at runtime, > so we should do as Matt says instead of checking the board revision at > runtime - see e.g., the MPC8313ERDB_33 vs. > MPC8313ERDB_66 targets. The HRCW_LOW change should also be #ifdeffed. > > Some other comments on this patch, now that I've taken a closer look: > > 1. it should be two patches - one for the CLKIN change, the other for > the dynamic remapping change. > > 2. update doc/README.mpc8360emds for 33 vs. 66 a la > doc/README.mpc8313erdb, and also for the remapping change, each update > in its corresponding patch. Might want to mention any dip switch > setting changes and the physical location of the oscillator so the user > is sure which one to use - CLKIN is the one closest to the JTAG > connector, right? Yes, it is U41. > 3. no need to sync after write_bat(); write_bat() does this already. > > 4. no need to clear BATs before writing them either. > > 5. I can't comprehend the comment "re-setup PCI MEM space used BAT5 > after relocated to DDR" - do you mean something like "reuse BAT5 for > PCI MEM space after relocation to RAM"? Yes, I will change the comment. > 6. re-post patches to this thread - see the 3rd bullet in: > > http://www.denx.de/wiki/view/U- > Boot/Patches#Sending_updated_patch_versions > > Thanks, > > Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] MPC8360EMDS: 512MB DDR and 33.33MHz oscillator support
Thanks and Best Regards Jerry Huang > -Original Message- > From: McClintock Matthew-B29882 > Sent: Wednesday, November 02, 2011 10:52 PM > To: Huang Changming-R66093 > Cc: Tabi Timur-B04825; u-boot@lists.denx.de; Phillips Kim-R1AAHA > Subject: Re: [U-Boot] [PATCH v5] MPC8360EMDS: 512MB DDR and 33.33MHz > oscillator support > > On Wed, Nov 2, 2011 at 2:34 AM, Huang Changming-R66093 > wrote: > >> > How can I deal with the new board and old board? > >> > >> Check the board revision at runtime. > >> > > Board Specification says, there is one EEPROM to contain all board > history, and I found it: > > On I2C2 bus, there is one EEPROM BRD(0x50) from the schematics, but > the content of this EEPROM is 0xff. > > That's to say, we can't check the board information from this EEPROM. > > From the code of mpc8360emds platform, there is not the interface to > check the board information. > > > > So, there is no way to check the board revision at runtime. > > Is your board special? Maybe the ones customers get go through the > proper process to have EEPROM updated? Otherwise, you will probably > need to create a new board type: No, I have two boards, one was used for BSP development, and the other was ordered in Aug. > $ make mpc8360emds_newmodifier > It make sense. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] MPC8360EMDS: 512MB DDR and 33.33MHz oscillator support
Thanks and Best Regards Jerry Huang > -Original Message- > From: Tabi Timur-B04825 > Sent: Wednesday, November 02, 2011 11:25 AM > To: Huang Changming-R66093 > Cc: Phillips Kim-R1AAHA; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH v5] MPC8360EMDS: 512MB DDR and 33.33MHz > oscillator support > > On Tue, Nov 1, 2011 at 9:08 PM, Huang Changming-R66093 > wrote: > > Kim, > > Since 2008, the boards shipped to customer are the new boards with > 33.33MHz oscillator and 512MB DDR. > > How can I deal with the new board and old board? > > Check the board revision at runtime. > Board Specification says, there is one EEPROM to contain all board history, and I found it: On I2C2 bus, there is one EEPROM BRD(0x50) from the schematics, but the content of this EEPROM is 0xff. That's to say, we can't check the board information from this EEPROM. >From the code of mpc8360emds platform, there is not the interface to check the >board information. So, there is no way to check the board revision at runtime. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] MPC8360EMDS: 512MB DDR and 33.33MHz oscillator support
Kim, Since 2008, the boards shipped to customer are the new boards with 33.33MHz oscillator and 512MB DDR. How can I deal with the new board and old board? Thanks and Best Regards Jerry Huang > -Original Message- > From: Phillips Kim-R1AAHA > Sent: Wednesday, November 02, 2011 7:53 AM > To: Huang Changming-R66093 > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH v5] MPC8360EMDS: 512MB DDR and 33.33MHz > oscillator support > > On Thu, 27 Oct 2011 13:47:48 +0800 > wrote: > > > From: Jerry Huang > > > > The new MPC8360EMDS board changes the oscillator to 33.33MHz in order > > to support QE 500MHZ and this new board supports 512MB DDR since 2008, > > but the u-boot only supports 256MB DDR and 66.6MHz oscillator on top > > tree, > > > > For 512MB DDR: > > BAT0 is used for the first 256MB memory, BAT4 is used for the second > > 256MB memory and the address space of SDRAM follows the DDR, so if > the > > size of DDR is 256MB, the BAT4 will be used for SDRAM and if the size > > of DDR is 512MB, the BAT4 will be used for the second 256MB memory > and > > there is no BAT for SDRAM. > > Therefore, if the size of DDR is 512MB, this patch will use BAT6 for > > SDRAM and BAT5 will be used for PCI MEM to replace the BAT6 after the > > codes relocates to the DDR. > > > > Signed-off-by: Jerry Huang > > --- > > cahnges for v2: > > - fix multiline comment wrong > > changes for v3: > > - change the oscillator to , not 3330 changes for v4: > > - add the mandatory history of changes changes for v5: > > - move the code to platform file from lib/board.c > > - add 2011 copyright > > NAK - this patch bricks my (older) mpc8360emds board. > > Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become bus master out of reset
Thanks and Best Regards Jerry Huang > -Original Message- > From: Heiko Schocher [mailto:h...@denx.de] > Sent: Friday, October 28, 2011 2:34 PM > To: Huang Changming-R66093 > Cc: Joakim Tjernlund; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become bus > master out of reset > > Hello Huang Changming-R66093, > > Huang Changming-R66093 wrote: > >>> These tow part codes are doing the different thing due to the > >> different reason: > >>> 1. Kernel's code: > >>> because Sometimes 9th clock pulse isn't generated, that code is to > >> generate the 9th clock pulse. > >> > >> What code are you looking at? Are you just reading the comment? > >> Look at http://git.kernel.org/?p=linux/kernel/git/next/linux- > >> next.git;a=commit;h=0c2daaafcdec726e89cbccca61d576de8429c537 > >> to get a clue. > >> > >> Your code isn't complete, you cannot trust the manual to be the > whole > >> truth. > >> > > I am very confused, why do you always say my code isn't complete? > > Because it is not complete? I don't think it is not complete, because this patch resolves my issue. > > I have described I want to do detailed in comment. > > "when a system reset does not cause all I2C devices to be reset", > > You wrote: > "So, the kernel's patch and my patch is to resolve the different > issue." > > Yes! There are more "problems" on i2c bus, as also Joakim described! > And if we try to fix them in the common driver (as you did), we should > fix all known problems -> so your patch is incomplete. Yes, we should fix all known problems, but we should not hope one patch includes everything. it make sense for one patch to resolve one thing, instead of all. > > My codes will force the I2c module to become bus master and drive SCL, > > which force this i2c module to generate SCL so that the device > driving SDA can finish its transaction. > > These codes have been used on Emerson's P1022 board and resolved his > > issue (board will hang when u-boot booting, with my codes, this issue > > is resolved and board can boot well) > > Then you maybe define CONFIG_SYS_I2C_BOARD_LATE_INIT for this board and > do this in board code. I have pointed out, this is one feature of FSL I2C module and almost cover all 85xx platform, we provides one solution to resolve the i2c bus "reset" issue. So I think it is not necessary to define one macro for one special board. > > This is one feature of FSL I2C almost cover all 85xx platform, and > the code according to the RM has been verified, don't you think the > manual can be trust? > > See (for example on a mpc83xx based board) > board/keymile/common/common.c functions i2c_write_start_seq() and > i2c_make_abort() which solve also a deblocked i2c bus ... and they > started with the procedure noted in the RM, but this didn't solved all > issues for them. > > > Below is the description from your link: > > This patch improves the recovery of the MPC's I2C bus from errors > like > > bus hangs resulting in timeouts: > > 1. make the bus timeout configurable, as it depends on the bus clock > and > > the attached slave chip(s); default is still 1 second; 2. detect > > any of the cases indicated by the CF, BB and RXAK MSR flags if a > > timeout occurs, and add a missing (required) MAL reset; 3. use a > > more reliable method to fixup the bus if a hang has been detected. > > The sequence is sent 9 times which seems to be necessary if a > slave > > "misses" more than one clock cycle. For 400 kHz bus speed, the > fixup is > > also ~70us (81us vs. 150us) faster. > > > > This patch is created because a slave miss more than one clock cycle > and can resolve this issue. > > > > So, the kernel's patch and my patch is to resolve the different issue. > > Yes, and if editing a common driver, we should find a solution which > fit for all ... did you tried the linux driver code for your board? > Maybe it solves your problem too? So we can adapt it to u-boot code? > I can't try the Linux driver on my boards, because all boards on my hand has not these two i2c issue. These codes is generated according to FSL Reference Manual, if you check the RM of FSL, you will find out all 85xx chips(now I know) support this feature. And these code can be work on Emerson's p1022 board, if the code according to the RM can work, I don't think I have any reason to ask customer to use the other codes. And the solution RM provide can resolve the issue, why don't we trust the RM? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become bus master out of reset
> > > > > These tow part codes are doing the different thing due to the > different reason: > > 1. Kernel's code: > > because Sometimes 9th clock pulse isn't generated, that code is to > generate the 9th clock pulse. > > What code are you looking at? Are you just reading the comment? > Look at http://git.kernel.org/?p=linux/kernel/git/next/linux- > next.git;a=commit;h=0c2daaafcdec726e89cbccca61d576de8429c537 > to get a clue. > > Your code isn't complete, you cannot trust the manual to be the whole > truth. > I am very confused, why do you always say my code isn't complete? I have described I want to do detailed in comment. "when a system reset does not cause all I2C devices to be reset", My codes will force the I2c module to become bus master and drive SCL, which force this i2c module to generate SCL so that the device driving SDA can finish its transaction. These codes have been used on Emerson's P1022 board and resolved his issue (board will hang when u-boot booting, with my codes, this issue is resolved and board can boot well) This is one feature of FSL I2C almost cover all 85xx platform, and the code according to the RM has been verified, don't you think the manual can be trust? Below is the description from your link: This patch improves the recovery of the MPC's I2C bus from errors like bus hangs resulting in timeouts: 1. make the bus timeout configurable, as it depends on the bus clock and the attached slave chip(s); default is still 1 second; 2. detect any of the cases indicated by the CF, BB and RXAK MSR flags if a timeout occurs, and add a missing (required) MAL reset; 3. use a more reliable method to fixup the bus if a hang has been detected. The sequence is sent 9 times which seems to be necessary if a slave "misses" more than one clock cycle. For 400 kHz bus speed, the fixup is also ~70us (81us vs. 150us) faster. This patch is created because a slave miss more than one clock cycle and can resolve this issue. So, the kernel's patch and my patch is to resolve the different issue. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become bus master out of reset
> > > > The above sequence is different than the kernel version, why? > > > > > > I don't know the kernel version, but I write the u-boot code > according > > > to the Reference Manual of PowerPC, e.g p1022: > > > 11.5.6 Generation of SCL When SDA Low > > > It is sometimes necessary to force the I2C module to become the I2C > bus > > > master out of reset and drive SCL(even though SDA may already be > driven, > > > which indicates that the bus is busy). This can occur when a system > > > reset does not cause all I2C devices to be reset. Thus, SDA can be > > > driven low by another I2C device while this I2C module is coming > out of > > > reset and stays low indefinitely. The following procedure can be > used > > > to force this I2C module to generate SCL so that the device driving > SDA > > > can finish its transaction: > > > 1. Disable the I2C module and set the master bit by setting I2CCR > to > > > 0x20 > > > 2. Enable the I2C module by setting I2CCR to 0xA0 > > > 3. Read the I2CDR > > > 4. Return the I2C module to slave mode by setting I2CCR to 0x80 > > > > > Compare with kernel version, the difference is one line: > > Uboot: readb(&dev->dr); > > Kernel has no any operation. > > But, I check the comment of kernel, because the 9th clock pulse isn't > generated, > > the sequence of function mpc_i2c_fixup is needed to generate 9th > clock pulse. > > Not so, there is more than that if you look closer. The description in > the kernel > is a bit misleading(or so I think). I prefer the kernel version for 2 > reasons: > 1) It has been there for quite some time so if there were something > wrong with, >it should have been noticed by now. > 2) I have a vauge memory of checking it again the mpc8321 manual and I > was happy >with it. > These tow part codes are doing the different thing due to the different reason: 1. Kernel's code: because Sometimes 9th clock pulse isn't generated, that code is to generate the 9th clock pulse. It happens in the DATA transfer stage. 2. My code: because the system reset does not cause all I2C devices to be reset, the code force the i2c to become the master and drive the SCL. It happens in the i2c controller initialize stage So, I think these code is reasonable. BTW: My codes has been verified on Emerson's board. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become bus master out of reset
> > > > > > > > The above sequence is different than the kernel version, why? > > > > > > I don't know the kernel version, but I write the u-boot code > according > > > to the Reference Manual of PowerPC, e.g p1022: > > > 11.5.6 Generation of SCL When SDA Low > > > It is sometimes necessary to force the I2C module to become the I2C > bus > > > master out of reset and drive SCL(even though SDA may already be > driven, > > > which indicates that the bus is busy). This can occur when a system > > > reset does not cause all I2C devices to be reset. Thus, SDA can be > > > driven low by another I2C device while this I2C module is coming > out of > > > reset and stays low indefinitely. The following procedure can be > used > > > to force this I2C module to generate SCL so that the device driving > SDA > > > can finish its transaction: > > > 1. Disable the I2C module and set the master bit by setting I2CCR > to > > > 0x20 > > > 2. Enable the I2C module by setting I2CCR to 0xA0 > > > 3. Read the I2CDR > > > 4. Return the I2C module to slave mode by setting I2CCR to 0x80 > > > > > Compare with kernel version, the difference is one line: > > Uboot: readb(&dev->dr); > > Kernel has no any operation. > > But, I check the comment of kernel, because the 9th clock pulse isn't > generated, > > the sequence of function mpc_i2c_fixup is needed to generate 9th > clock pulse. > > Not so, there is more than that if you look closer. The description in > the kernel > is a bit misleading(or so I think). I prefer the kernel version for 2 > reasons: > 1) It has been there for quite some time so if there were something > wrong with, >it should have been noticed by now. > 2) I have a vauge memory of checking it again the mpc8321 manual and I > was happy >with it. > These tow part codes are doing the different thing due to the different reason: 1. Kernel's code: because Sometimes 9th clock pulse isn't generated, that code is to generate the 9th clock pulse. It happens in the DATA transfer stage. 2. My code: because the system reset does not cause all I2C devices to be reset, the code force the i2c to become the master and drive the SCL. It happens in the i2c controller initialize stage So, I think these code is reasonable. BTW: My codes has been verified on Emerson's board. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become bus master out of reset
Thanks and Best Regards
Jerry Huang
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Huang Changming-R66093
> Sent: Thursday, October 27, 2011 3:40 PM
> To: Joakim Tjernlund
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become bus
> master out of reset
>
>
>
> Thanks and Best Regards
> Jerry Huang
>
>
> > -Original Message-
> > From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se]
> > Sent: Thursday, October 27, 2011 3:26 PM
> > To: Huang Changming-R66093
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become
> bus
> > master out of reset
> >
> > > From:
> > >
> > > From: Jerry Huang
> > >
> > > It is sometimes necessary to force the I2C module to become the I2C
> > > bus master out of reset and drive SCL(even though SDA may already
> be
> > > driven, which indicates that the bus is busy). This can occur when
> a
> > > system reset does not cause all I2C devices to be reset. Thus, SDA
> > can
> > > be driven low by another I2C device while this I2C module is coming
> > > out of reset and stays low indefinitely. The following procedure
> can
> > > be used to force this I2C module to generate SCL so that the device
> > > driving SDA can finish its transaction.
> > >
> > > Signed-off-by: Jerry Huang
> > > ---
> > > drivers/i2c/fsl_i2c.c | 18 ++
> > > 1 files changed, 18 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c index
> > > 258be0a..007db70 100644
> > > --- a/drivers/i2c/fsl_i2c.c
> > > +++ b/drivers/i2c/fsl_i2c.c
> > > @@ -252,6 +252,24 @@ i2c_init(int speed, int slaveadd)
> > >writeb(slaveadd << 1, &dev->adr);/* write slave address */
> > >writeb(0x0, &dev->sr); /* clear status register */
> > >writeb(I2C_CR_MEN, &dev->cr); /* start I2C controller */
> > > +
> > > + /* Force I2C module to become bus master which can occure
> when
> > > + * a system reset does not cause all I2C devices to be reset
> > */
> > > + udelay(5);
> > > + if (readb(&dev->sr) & I2C_SR_MBB) {
> >
> > You need to the sequence unconditionally, the slave can be stuck
> > without driving SCL.
> >
> > > + writeb(I2C_CR_MSTA, &dev->cr);
> > > + udelay(5);
> > > + writeb(I2C_CR_MEN | I2C_CR_MSTA, &dev->cr);
> > > + udelay(5);
> > > + readb(&dev->dr);
> > > + udelay(5);
> > > + writeb(I2C_CR_MEN, &dev->cr);
> > > + udelay(5);
> > > + if (readb(&dev->sr) & I2C_SR_MBB)
> > > +debug("I2C%d: Drive SCL failed\n", i + 1);
> > > + else
> > > +debug("I2C%d: Drive SCL succeed\n", i + 1);
> > > + }
> >
> > The above sequence is different than the kernel version, why?
>
> I don't know the kernel version, but I write the u-boot code according
> to the Reference Manual of PowerPC, e.g p1022:
> 11.5.6 Generation of SCL When SDA Low
> It is sometimes necessary to force the I2C module to become the I2C bus
> master out of reset and drive SCL(even though SDA may already be driven,
> which indicates that the bus is busy). This can occur when a system
> reset does not cause all I2C devices to be reset. Thus, SDA can be
> driven low by another I2C device while this I2C module is coming out of
> reset and stays low indefinitely. The following procedure can be used
> to force this I2C module to generate SCL so that the device driving SDA
> can finish its transaction:
> 1. Disable the I2C module and set the master bit by setting I2CCR to
> 0x20
> 2. Enable the I2C module by setting I2CCR to 0xA0
> 3. Read the I2CDR
> 4. Return the I2C module to slave mode by setting I2CCR to 0x80
>
Compare with kernel version, the difference is one line:
Uboot: readb(&dev->dr);
Kernel has no any operation.
But, I check the comment of kernel, because the 9th clock pulse isn't
generated,
the sequence of function mpc_i2c_fixup is needed to generate 9th clock pulse.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become bus master out of reset
Thanks and Best Regards
Jerry Huang
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se]
> Sent: Thursday, October 27, 2011 3:26 PM
> To: Huang Changming-R66093
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become bus
> master out of reset
>
> > From:
> >
> > From: Jerry Huang
> >
> > It is sometimes necessary to force the I2C module to become the I2C
> > bus master out of reset and drive SCL(even though SDA may already be
> > driven, which indicates that the bus is busy). This can occur when a
> > system reset does not cause all I2C devices to be reset. Thus, SDA
> can
> > be driven low by another I2C device while this I2C module is coming
> > out of reset and stays low indefinitely. The following procedure can
> > be used to force this I2C module to generate SCL so that the device
> > driving SDA can finish its transaction.
> >
> > Signed-off-by: Jerry Huang
> > ---
> > drivers/i2c/fsl_i2c.c | 18 ++
> > 1 files changed, 18 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c index
> > 258be0a..007db70 100644
> > --- a/drivers/i2c/fsl_i2c.c
> > +++ b/drivers/i2c/fsl_i2c.c
> > @@ -252,6 +252,24 @@ i2c_init(int speed, int slaveadd)
> >writeb(slaveadd << 1, &dev->adr);/* write slave address */
> >writeb(0x0, &dev->sr); /* clear status register */
> >writeb(I2C_CR_MEN, &dev->cr); /* start I2C controller */
> > +
> > + /* Force I2C module to become bus master which can occure when
> > + * a system reset does not cause all I2C devices to be reset
> */
> > + udelay(5);
> > + if (readb(&dev->sr) & I2C_SR_MBB) {
>
> You need to the sequence unconditionally, the slave can be stuck
> without driving SCL.
>
> > + writeb(I2C_CR_MSTA, &dev->cr);
> > + udelay(5);
> > + writeb(I2C_CR_MEN | I2C_CR_MSTA, &dev->cr);
> > + udelay(5);
> > + readb(&dev->dr);
> > + udelay(5);
> > + writeb(I2C_CR_MEN, &dev->cr);
> > + udelay(5);
> > + if (readb(&dev->sr) & I2C_SR_MBB)
> > +debug("I2C%d: Drive SCL failed\n", i + 1);
> > + else
> > +debug("I2C%d: Drive SCL succeed\n", i + 1);
> > + }
>
> The above sequence is different than the kernel version, why?
I don't know the kernel version, but I write the u-boot code according to the
Reference Manual of PowerPC, e.g p1022:
11.5.6 Generation of SCL When SDA Low
It is sometimes necessary to force the I2C module to become the I2C bus master
out of reset and drive SCL(even though SDA may already be driven, which
indicates that the bus is busy). This can occur when a system reset does not
cause all I2C devices to be reset. Thus, SDA can be driven low by another I2C
device while this I2C module is coming out of reset and stays low indefinitely.
The following procedure can be used to force this I2C module to generate SCL so
that the device driving SDA can finish its transaction:
1. Disable the I2C module and set the master bit by setting I2CCR to 0x20
2. Enable the I2C module by setting I2CCR to 0xA0
3. Read the I2CDR
4. Return the I2C module to slave mode by setting I2CCR to 0x80
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
