Re: [U-Boot-Users] [PATCH 1/2] AT572D940HF-EB Support v2 (SDHC support part 1)
On 08:38 Fri 13 Jun , Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > > > > If you want to see changes right now, > > then just replace the existing file with the Diopsis file and do a diff. > > No, this is not the way we work. We submit patches that can be > reviewed, not chunks of code that the reviewer has to anayze with > additional, unnecessary efforts. > > > Why not get the Diopsis support in first, and then do the merge afterwards. IMO: I could apply this patch in a testing branch but I've the same opinion as Wolfgang and Haavard. > > Because this is NOT the way it works. > > Please stick to the established rules. > Best Regards, J. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/2] AT572D940HF-EB Support v2 (SDHC support part 1)
"Ulf Samuelsson" <[EMAIL PROTECTED]> wrote: > > No, this is not the way we work. We submit patches that can be > > reviewed, not chunks of code that the reviewer has to anayze with > > additional, unnecessary efforts. > > Antonio submits a working patchset which is structured in the > same manner as existing boards. > Haavard has a different goal which is important, but less urgent than other > things. What the hell makes you think that your goals are so much more important than mine (and everyone else's for that matter)? It's much easier to get the drivers merged now rather than later. I did actually do a quick diff and I saw at least three minor fixes reverted, so the drivers have _already_ started diverging. Do you think they will somehow be _more_ similar if we just keep them in the same tree for a while? Besides, there's a very real possibility that the drivers will never be merged since we're all busy with other stuff. Btw, apart from a couple of relatively minor things, I think the diff as a whole looked very good, so that's not at all what I'm complaining about. > >> Why not get the Diopsis support in first, and then do the merge > >> afterwards. > > > > Because this is NOT the way it works. > > Please stick to the established rules. > > Which rule is you referring to? > > Since Haavard wants this merge, then I suggest that Haavard takes > the existing patches from Antonio and reworks them ASAP, > testing them out on AVR32, AT91 and Diopsis, and resubmits > the patchset so that we have a working common driver > and working AT572D940DF board support. Ulf, if you keep insisting on that attitude, you'll never get anything merged. This is _so_ not how it works. I can certainly help Antonio get the patch into an acceptable state for merging as well as test it on AVR32, but demanding that I set up toolchains and test every single Atmel board out there is just totally unreasonable. Besides, the driver was originally written by me. Isn't it fair that Diopsis gave something back by making it usable on more than just their board? Haavard - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/2] AT572D940HF-EB Support v2 (SDHC support part 1)
Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: >> >> If you want to see changes right now, >> then just replace the existing file with the Diopsis file and do a >> diff. > > No, this is not the way we work. We submit patches that can be > reviewed, not chunks of code that the reviewer has to anayze with > additional, unnecessary efforts. Antonio submits a working patchset which is structured in the same manner as existing boards. Haavard has a different goal which is important, but less urgent than other things. >> Why not get the Diopsis support in first, and then do the merge >> afterwards. > > Because this is NOT the way it works. > Please stick to the established rules. Which rule is you referring to? Since Haavard wants this merge, then I suggest that Haavard takes the existing patches from Antonio and reworks them ASAP, testing them out on AVR32, AT91 and Diopsis, and resubmits the patchset so that we have a working common driver and working AT572D940DF board support. Haavard, There is an AT572D940HF-EB in Atmel Norway, I gave it to OJ and he should forward it to Haakan. Do you have any AT91 boards? > > Best regards, > > Wolfgang Denk Best Regards Ulf Samuelsson[EMAIL PROTECTED] Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM+46 (706) 22 44 57 Technical support when I am not available: AT90 AVR Applications Group: mailto:[EMAIL PROTECTED] AT91 ARM Applications Group: mailto:[EMAIL PROTECTED] AVR32 Applications Groupmailto:[EMAIL PROTECTED] http://www.avrfreaks.net/;http://avr32linux.org/ http://www.at91.com/ ; http://www.linux4sam.org/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/2] AT572D940HF-EB Support v2 (SDHC support part 1)
In message <[EMAIL PROTECTED]> you wrote: > > If you want to see changes right now, > then just replace the existing file with the Diopsis file and do a diff. No, this is not the way we work. We submit patches that can be reviewed, not chunks of code that the reviewer has to anayze with additional, unnecessary efforts. > Why not get the Diopsis support in first, and then do the merge afterwards. Because this is NOT the way it works. Please stick to the established rules. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Whom the gods would destroy, they first teach BASIC. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/2] AT572D940HF-EB Support v2 (SDHC support part 1)
Haavard Skinnemoen wrote: > On Thu, 12 Jun 2008 19:19:47 +0200 > "Ulf Samuelsson" <[EMAIL PROTECTED]> wrote: > >> Haavard Skinnemoen wrote: >>> It's a bit hard to see what your proposal is all about when you >>> create a new file instead of modifying the exising one... >>> >> >> If you want to see changes right now, >> then just replace the existing file with the Diopsis file and do a >> diff. > > The whole idea about e-mail review is that someone posts a patch and > someone else reviews it. >>> So how about we start by introducing a new drivers/mmc directory and >>> move the existing AVR32 driver there? After that, you can apply your >>> changes to it and send a patch which clearly shows the differences >>> from the old code. Don't worry about breaking AVR32 -- I'll help you >>> test it before it gets merged upstream. >>> >> >> Why not get the Diopsis support in first, and then do the merge >> afterwards. I do agree that they should be merged, but that does not >> mean >> that delaying the availability of Diopsis support in U-Boot is a >> good idea. > > I disagree. Why do a half-assed job when you can do it properly? Some times half-assed jobs, are good enough, and if you concentrate all your efforts on one parts, then everything else suffers. Currently the Diopsis configuration does not support environment variables, and I much rather have Antonio spend time on fixing that problem, than merging the MCI support. Either by using the onboard parallel flash (which is complicated since it is 2 x 16 bit AT45BV64x chips in a by 32 configuration). I am really unsure U-boot supports this... Or figures out a way to read/write the environment from/to the SD-Card. While the duplication is unfortunate, the end user will not suffer too much compared to not having environment variables. > Besides, the merge window is closed now, isn't it? So we have lots of > time to review and test things before the next merge window. > > Haavard Best Regards Ulf Samuelsson - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/2] AT572D940HF-EB Support v2 (SDHC support part 1)
On Thu, 12 Jun 2008 19:19:47 +0200 "Ulf Samuelsson" <[EMAIL PROTECTED]> wrote: > Haavard Skinnemoen wrote: > > It's a bit hard to see what your proposal is all about when you create > > a new file instead of modifying the exising one... > > > > If you want to see changes right now, > then just replace the existing file with the Diopsis file and do a diff. The whole idea about e-mail review is that someone posts a patch and someone else reviews it. > > So how about we start by introducing a new drivers/mmc directory and > > move the existing AVR32 driver there? After that, you can apply your > > changes to it and send a patch which clearly shows the differences > > from the old code. Don't worry about breaking AVR32 -- I'll help you > > test it before it gets merged upstream. > > > > Why not get the Diopsis support in first, and then do the merge afterwards. > I do agree that they should be merged, but that does not mean > that delaying the availability of Diopsis support in U-Boot is a good idea. I disagree. Why do a half-assed job when you can do it properly? Besides, the merge window is closed now, isn't it? So we have lots of time to review and test things before the next merge window. Haavard - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/2] AT572D940HF-EB Support v2 (SDHC support part 1)
Haavard Skinnemoen wrote: > On Thu, 12 Jun 2008 16:14:56 +0200 > "Antonio R. Costa" <[EMAIL PROTECTED]> wrote: > >> This patch add support for SD/SDHC cards to AT572D940HF-EB >> and more generally is a proposal for all Atmel chips. >> Dued to that I placed atmel_mci.c under the board directory. > > It's a bit hard to see what your proposal is all about when you create > a new file instead of modifying the exising one... > If you want to see changes right now, then just replace the existing file with the Diopsis file and do a diff. >> The implementation of the CSD interpretation has been re-worked >> completely. Bit fields are not portable so there were replaced by >> a vector of 4 32-bit words and some macros. >> >> Probing process follow the schema from SD spec 2.0: >> sdhc --> sd --> mmc >> >> Introduced IF_TYPE_SDHC to distinguish between SD and SDHC. >> Maybe this is not the best method since struct block_dev_descr.priv >> could point to a structure describing card properties but it was >> the quickest one and I had no time to spend. >> >> Tested SD: >> - Mediacom512 MB (spec 1.0) bare FAT16 no partition table >> - Kingstone 1 GB (spec 1.0) 1 FAT16 >> - Trascend 2 GB (spec 1.01) 1 FAT16 >> - TakeMS4 GB (spec 1.10) 1 FAT16 >> >> Tested SDHC: >> - Peak 8 GB (spec 2.0) 1 FAT32 > > Ideally, this sort of thing should go into a common MMC layer for > u-boot. But at the very least, we should use the same driver on all > chips that feature the same hardware (other AT91 chips and AVR32). > So how about we start by introducing a new drivers/mmc directory and > move the existing AVR32 driver there? After that, you can apply your > changes to it and send a patch which clearly shows the differences > from the old code. Don't worry about breaking AVR32 -- I'll help you > test it before it gets merged upstream. > Why not get the Diopsis support in first, and then do the merge afterwards. I do agree that they should be merged, but that does not mean that delaying the availability of Diopsis support in U-Boot is a good idea. > Then, after that, if someone feels up to the task, he can gather all > the different pieces together from the existing drivers and create a > common MMC layer. > > Does that sound like a good plan to you? > > Haavard > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > U-Boot-Users mailing list > U-Boot-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users Best Regards Ulf Samuelsson - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/2] AT572D940HF-EB Support v2 (SDHC support part 1)
On Thu, 12 Jun 2008 16:14:56 +0200 "Antonio R. Costa" <[EMAIL PROTECTED]> wrote: > This patch add support for SD/SDHC cards to AT572D940HF-EB > and more generally is a proposal for all Atmel chips. > Dued to that I placed atmel_mci.c under the board directory. It's a bit hard to see what your proposal is all about when you create a new file instead of modifying the exising one... > The implementation of the CSD interpretation has been re-worked > completely. Bit fields are not portable so there were replaced by > a vector of 4 32-bit words and some macros. > > Probing process follow the schema from SD spec 2.0: > sdhc --> sd --> mmc > > Introduced IF_TYPE_SDHC to distinguish between SD and SDHC. > Maybe this is not the best method since struct block_dev_descr.priv > could point to a structure describing card properties but it was > the quickest one and I had no time to spend. > > Tested SD: > - Mediacom512 MB (spec 1.0) bare FAT16 no partition table > - Kingstone 1 GB (spec 1.0) 1 FAT16 > - Trascend 2 GB (spec 1.01) 1 FAT16 > - TakeMS4 GB (spec 1.10) 1 FAT16 > > Tested SDHC: > - Peak 8 GB (spec 2.0) 1 FAT32 Ideally, this sort of thing should go into a common MMC layer for u-boot. But at the very least, we should use the same driver on all chips that feature the same hardware (other AT91 chips and AVR32). So how about we start by introducing a new drivers/mmc directory and move the existing AVR32 driver there? After that, you can apply your changes to it and send a patch which clearly shows the differences from the old code. Don't worry about breaking AVR32 -- I'll help you test it before it gets merged upstream. Then, after that, if someone feels up to the task, he can gather all the different pieces together from the existing drivers and create a common MMC layer. Does that sound like a good plan to you? Haavard - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/2] AT572D940HF-EB Support v2 (SDHC support part 1)
This patch add support for SD/SDHC cards to AT572D940HF-EB
and more generally is a proposal for all Atmel chips.
Dued to that I placed atmel_mci.c under the board directory.
Plaese give me some feedbacks.
The implementation of the CSD interpretation has been re-worked
completely. Bit fields are not portable so there were replaced by
a vector of 4 32-bit words and some macros.
Probing process follow the schema from SD spec 2.0:
sdhc --> sd --> mmc
Introduced IF_TYPE_SDHC to distinguish between SD and SDHC.
Maybe this is not the best method since struct block_dev_descr.priv
could point to a structure describing card properties but it was
the quickest one and I had no time to spend.
Tested SD:
- Mediacom512 MB (spec 1.0) bare FAT16 no partition table
- Kingstone 1 GB (spec 1.0) 1 FAT16
- Trascend 2 GB (spec 1.01) 1 FAT16
- TakeMS4 GB (spec 1.10) 1 FAT16
Tested SDHC:
- Peak 8 GB (spec 2.0) 1 FAT32
Signed-off-by: Antonio R. Costa <[EMAIL PROTECTED]>
diff --git a/board/atmel/at572d940hfeb/atmel_mci.c
b/board/atmel/at572d940hfeb/atmel_mci.c
new file mode 100644
index 000..2aa2588
--- /dev/null
+++ b/board/atmel/at572d940hfeb/atmel_mci.c
@@ -0,0 +1,799 @@
+/*
+ * (C) Copyright 2008 Atmel Corporation
+ *
+ * Antonio R. Costa atmel.com>
+ * gmail.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+
+#ifdef CONFIG_MMC
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#ifdef DEBUG
+#define pr_debug(fmt, args...) printf(fmt, ##args)
+#else
+#define pr_debug(...) do { } while(0)
+#endif
+
+#ifndef CFG_MMC_CLK_OD
+#define CFG_MMC_CLK_OD 15
+#endif
+
+#ifndef CFG_MMC_CLK_PP
+#define CFG_MMC_CLK_PP 500
+#endif
+
+#ifndef CFG_MMC_OP_COND
+#define CFG_MMC_OP_COND0x401f8000
+#endif
+
+#define MMC_DEFAULT_BLKLEN 512
+#define MMC_DEFAULT_RCA1
+
+static unsigned int mmc_rca;
+static int mmc_card_is_sd;
+static block_dev_desc_t mmc_blkdev;
+
+block_dev_desc_t *mmc_get_dev(int dev)
+{
+ return &mmc_blkdev;
+}
+
+static int mci_reset(void)
+{
+
+ mmci_writel(CR, MMCI_BIT(SWRST));
+ mmci_writel(CR, MMCI_BIT(MCIEN));
+ mmci_writel(CR, MMCI_BIT(PWSDIS));
+
+ mmci_writel(CMDR, (1 << 11) | (1 << 8));/* Init command */
+ while (!(mmci_readl(SR) & MMCI_BIT(CMDRDY))) ;
+ return 0;
+}
+
+static void mci_set_mode(unsigned long hz, unsigned long blklen)
+{
+ unsigned long bus_hz;
+ unsigned long clkdiv;
+
+ bus_hz = get_mci_clk_rate();
+ clkdiv = (bus_hz / hz) / 2 - 1;
+
+ pr_debug("mmc: setting clock %lu Hz, clkdiv %lu, block size %lu\n",
+hz, clkdiv, blklen);
+
+ if (clkdiv & ~255UL) {
+ clkdiv = 255;
+ printf("mmc: clock %lu too low; setting CLKDIV to 255\n",
+ hz);
+ }
+
+ blklen &= 0xfffc;
+ mmci_writel(MR, (MMCI_BF(CLKDIV, clkdiv)
+| MMCI_BF(BLKLEN, blklen)
+| MMCI_BIT(RDPROOF)
+| MMCI_BIT(WRPROOF)));
+}
+
+#define RESP_NO_CRC1
+#define R1 MMCI_BF(RSPTYP, 1) /* 48-bit CRC */
+#define R2 MMCI_BF(RSPTYP, 2) /* 136-bit CRC*/
+#define R3 (R1 | RESP_NO_CRC)
+#define R6 R1
+#define R7 R1
+#define NIDMMCI_BF(MAXLAT, 0)
+#define NCRMMCI_BF(MAXLAT, 1)
+#define TRCMD_STARTMMCI_BF(TRCMD, 1)
+#define TRDIR_READ MMCI_BF(TRDIR, 1)
+#define TRTYP_BLOCKMMCI_BF(TRTYP, 0)
+#define INIT_CMD MMCI_BF(SPCMD, 1)
+#define OPEN_DRAIN MMCI_BF(OPDCMD, 1)
+
+#define ERROR_FLAGS(MMCI_BIT(DTOE) \
+| MMCI_BIT(RDIRE) \
+| MMCI_BIT(RENDE) \
+| MMCI_BIT(RINDE) \
+| MMCI_BIT(RTOE))
+
+static int
+mmc_cmd(unsigned long cmd, unsigned long arg, void *resp,
+ unsigned long flags)
+{
+ unsigned long *response = resp;
+ int i, response_words = 0;
+ unsigned l
