[U-Boot-Users] [PATCH 1/2] AT572D940HF-EB Support v2 (SDHC support part 1)

[Ulf Samuelsson <ulf.samuelsson@atmel.com>]

Haavard Skinnemoen wrote:
> On Thu, 12 Jun 2008 16:14:56 +0200
> "Antonio R. Costa" <costa.antonior@gmail.com> 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:
>>   - Mediacom    512 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
>>   - TakeMS        4 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

Best Regards
Ulf Samuelsson