[U-Boot-Users] AT91 NAND om AT91SAM9260EK

[Ulf Samuelsson]

>> Here is it again, was not sent as a tarball, but as an attachement.
>> This was a patchset of three patches, the remaining
>> two patches just removes
>> "board/at91rm9200dk/at45.c"     and
>> "board/cmc_pu2/at45.c"
>> They are not used any longer.
>
> Thanks. When I replied last time, I thought for some reason that this
> was a new driver even though I knew perfectly well it isn't. Anyway, I
> guess it makes the review process slightly different...
>
> I think the best way forward is probably to first get rid of the
> duplication by moving everything as-is into drivers. That way, there's
> only a single driver to clean up, not two.
>
> I suggest we try to create a patch series doing the following:
>  1. Eliminate any differences between the two at45.c drivers
>  2. Consolidate the two drivers into drivers/at45.c
>  3. Do a codingstyle cleanup of drivers/at45.c
>  4. Split out the SPI part into a separate driver
>  5. Make everything portable. This includes getting rid of all the
>     AT91FOO prefixing.
>  <insert additional cleanup steps here>

My priority is to have AT91SAM9x support inside U-Boot ASAP.
This approach creates all kinds of unneccessary critical paths
which will delay this

I would like to see the following atpproach.

1) at45_split is applied splitting into
    cpu independent part and cpu dependent part.
    the drivers/at45.c is siglty modified to handle
    at91rm9200dk and cmc_pu2 boards as well
    as the at91sam926xek boards
2) cpu/arm926ejs/at91sam926x AT91SAM9 support
    This has an spi.c which is different from
3) board patches applied
    board/at91sam9260ek
    board/at91sam9261ek
    board/at91sam9263ek
    board/at91rm9200ek
    board/at91rm9200df
    drivers/dataflash.c update to support linux-2.6 instead of linux-2.4

After that is in place, then it is time for your proposal.

1) Do a codingstyle cleanup of drivers/at45.c
2) Make everything portable.
    This includes getting rid of all the AT91FOO prefixing.

If we follow your approach, then the at91sam926x
SPI support has first to be inserted into at45.c and retested
only to be split up at a later stage.


>
> Wolfgang, does this sound like a good plan to you?
>
> Step #1 is easy:
>
> $ diff -up board/cmc_pu2/at45.c board/at91rm9200dk/at45.c
> --- board/cmc_pu2/at45.c        2006-08-30 21:53:30.000000000 +0200
> +++ board/at91rm9200dk/at45.c   2006-08-30 21:53:30.000000000 +0200
> @@ -593,7 +593,7 @@ int AT91F_DataFlashRead(
>                if (AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc, 
> AT91C_TIMEOUT_WRDY) != DATAFLASH_OK)
>                        return -1;
>
> -               if (AT91F_DataFlashContinuousRead (pDataFlash, addr, 
> buffer, SizeToRead) != DATAFLASH_OK)
> +               if (AT91F_DataFlashContinuousRead (pDataFlash, addr, 
> (uchar *)buffer, SizeToRead) != DATAFLASH_OK)
>                        return -1;
>
>                size -= SizeToRead;
>
> We'll just have to decide whether or not to keep the cast. buffer is a
> char * anyway, so I don't think it makes any difference at all.
>
> Step #2 will probably generate an oversize patch unless we do it as a
> git patch, which will basically just boil down to a rename and a
> deletion (where the deletion will be the biggest part, but still under
> 40KB I hope.)
>
> Step #3 is where the fun begins...
>
> I have a prototype board with DataFlash for ATSTK1000, so I can start
> testing on AVR32 around step #5. Before that, I'd appreciate some help
> testing the individual patches (I can do build testing on ARM though.)
>

I do not see anyone from the AT91 team participating in this effort
right now, and that is why I think we should apply
*tested* code to establish a base which is useful to at91sam9 users.

>> I do  think that it is better to submit the AT91SAM9 patches
>> first and  only then create a common driver.
>
> If the AT91SAM9 patches include another at45.c driver, I disagree.

The at91sam9 patchset has a board/at45.c and it is this that
is available in in the "at45_split" patch.
If at91_split is applied there will be no modification of this file
when the at91sam9 patchset is submitted.

> Better consolidate first and add new stuff on top of that. But the
> driver should be usable for new boards after step #2, so you probably
> don't have to wait very long before you can start submitting the SAM
> stuff.

the spi.c is very small and msot of the code relies on the pin multiplexing 
of the part.
This is why I think it may make little sense to have a common driver.


>
> Btw, Wolfgang: I'd really appreciate if you could pull the avr32 update
> from last november (which I rebased and resent last week):
>
> git://www.atmel.no/~hskinnemoen/u-boot/avr32.git for-wolfgang
>
> It will be a lot easier to support avr32 with a single, unified at45
> driver if those changes are in mainline. They simplify much of the
> portmux- clock- and I/O management code, thus making it easier to see
> what it takes to make the at45 and spi drivers portable across ARM and
> AVR32.
>
> Besides, you were the one who specifically asked me to add relocation
> support, which is what the update is really all about...
>
> Haavard
>


Best Regards
Ulf Samuelsson                ulf at atmel.com
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:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR