[U-Boot] [STATUS: AT91/AVR32]

[U-Boot] [STATUS: AT91/AVR32]

[Reinhard Meyer]

Hello AT91/AVR32 users and maintainers,

since relocation was introduced most ARM boards and therefore all AT91 based boards are
inherently broken.

We also used this "opportunity" to rework most of the AT91 include files mess.

You can find the current efforts at git.denx.de/u-boot-atmel.git, branch rework110202.

If you are going to fix a board, make sure you base on this branch and take the at91sam9260ek
port as an example how it can be done.

There is one important "catch" because of relocation relocates u-boot to top of available
RAM: U-boot should not be loaded near top of RAM by at91bootstrap anymore, otherwise there
is the risk that relocation will fail due to overlaps.
So you need to fix at91bootstrap to load u-boot to begin of RAM, or, at least,
not near the end of RAM. (It works fine to be loaded to begin of RAM.)

The at91sam9260ek port is proven to build and run.

Before submitting patches please check the following:

1. "#define XXXX 1" is depreciated if the "1"  is not of numeric significance, use "#define XXXX"
instead. Check your board config file for such occurrences.

2. SZ_ macros are depreciated, use (n << 10) for KiB, (n << 20) fir MiB, etc. Using
(n * 1024) or (n * 1024 * 1024) are also acceptable as well as other numeric values.
It is up to you what you prefer to be readable :)

3. Please run the patch through <linux>/scripts/checkpatch.pl; that will pinpoint coding style
errors. (I assume you do have a kernel tree somewhere.)

4. If you think you need to change generic AT91 files (header files other than for
9260/9261/9263 SoCs), please do so in the style of the 9260/9261/9263 header files,
but chancges to other AT91 files should not be necessary), please discuss this idea
in the list first.

5. *LEGACY defines should not be needed anymore.

6. reset_phy() seems to be an empty function for some boards. Please remove it and the
define that causes it to be called.

7. ...?

Unfortunately I am quite busy at work but I will try to comment and accept patches as
soon as time permits.

With Best Regards
Reinhard

PS: this list above might not be complete, clarifications and extensions are welcome :)

[U-Boot] [STATUS: AT91/AVR32]

[Reinhard Meyer]

Dear Uli Raich,
> Dear Reinhard,
> Many thanks for your answer. Only... I do not find a at91sam9260ek in this Makefile. I find at91sam9261ek or  at91sam92603ek though.
> Will try the at91sam92603ek config.
> Uli
1. please *always* reply to the list as well

2. Makefile is not relevant for new/fixed boards anymore.
New/fixed boards are added to boards.cfg (and have to be removed from Makefile)!

3. *ONLY* at91sam9260/9xeek are known to work! at91sam9263ek definitely is not working yet,
patches are in the pipeline.

Best Regards,
Reinhard

[U-Boot] [STATUS: AT91/AVR32]

[Remy Bohmer]

Hi Reinhard,

2011/2/8 Reinhard Meyer <u-boot@emk-elektronik.de>:
> Dear Uli Raich,
>> Dear Reinhard,
>> Many thanks for your answer. Only... I do not find a at91sam9260ek in this Makefile. I find at91sam9261ek or ?at91sam92603ek though.
>> Will try the at91sam92603ek config.
>> Uli
> 1. please *always* reply to the list as well
>
> 2. Makefile is not relevant for new/fixed boards anymore.
> New/fixed boards are added to boards.cfg (and have to be removed from Makefile)!
>
> 3. *ONLY* at91sam9260/9xeek are known to work! at91sam9263ek definitely is not working yet,
> patches are in the pipeline.

Well, the at91sam9261ek patches are pending and waiting for you to
pull them in, or at least waiting for your review comments.
AND these patches also work!

Kind regards,

Remy

[U-Boot] [STATUS: AT91/AVR32]

[Jens Scharsig]

Am 08.02.2011 16:35, schrieb Reinhard Meyer:
> Hello AT91/AVR32 users and maintainers,
> 
> since relocation was introduced most ARM boards and therefore all AT91 based boards are
> inherently broken.
> 
> We also used this "opportunity" to rework most of the AT91 include files mess.
> 
> You can find the current efforts at git.denx.de/u-boot-atmel.git, branch rework110202.
> 
Dear Reinhard Meyer,

I am maintainer of eb_cpux9k2 board and if you now do the soc rework 2009.

Currently the arm920t/at91 are not touched by your rework.

I can try to update the at91rm9200.h to the atmel_xxxx name scheme and update 
the two board in arm920t/at91 tree including drivers. 
Maybe I can still send a patch this week.

But I can't test the at91rm9200ek.

A second problem is, both boards use the legacy at91rm9200 usart driver. So we could try 
to use the  atmel_usart in a second step.


best regards 


Jens Scharsig

[U-Boot] [STATUS: AT91/AVR32]

[Andreas Bießmann]

Dear Jens Scharsig,

Am 08.02.2011 um 22:11 schrieb Jens Scharsig:

> Am 08.02.2011 16:35, schrieb Reinhard Meyer:
>> Hello AT91/AVR32 users and maintainers,
>> 
>> since relocation was introduced most ARM boards and therefore all AT91 based boards are
>> inherently broken.
>> 
>> We also used this "opportunity" to rework most of the AT91 include files mess.
>> 
>> You can find the current efforts at git.denx.de/u-boot-atmel.git, branch rework110202.
>> 
> Dear Reinhard Meyer,
> 
> I am maintainer of eb_cpux9k2 board and if you now do the soc rework 2009.
> 
> Currently the arm920t/at91 are not touched by your rework.
> 
> I can try to update the at91rm9200.h to the atmel_xxxx name scheme and update 
> the two board in arm920t/at91 tree including drivers. 
> Maybe I can still send a patch this week.
> 
> But I can't test the at91rm9200ek.

that would be my part ... BTW there was some interest for at91rm9200dk around christmas ...

> A second problem is, both boards use the legacy at91rm9200 usart driver. So we could try 
> to use the  atmel_usart in a second step.

The only thing missing is the 'unsigned long get_mck_clk_rate(void)' interface. I did test this some time ago but would prefer to have some code as in arm926ejs/at91/clock.c for arm920t too. Unfortunately did not have any time to do that right. I allege that some code in arm926ejs/at91/clock.c could be shared between arm920t/at91 and arm926ejs/at91. Would that allow some at91 specific code in arm/lib?

regards

Andreas Bie?mann

[U-Boot] [STATUS: AT91/AVR32]

[Uli Raich]

Dear Reinhard,
Point 1: taken and, as you can see, already improved upon
Point 2: I did not know the new configuration procedure even though I had seen the boards.cfg file. The description in the README file is outdated. I tried to compile the at91sam9260ek_nandflash version with success but failed on the dataflash versions.
Point 3: I have an old (1.3.4) working version for my "armuter-vmax" board, which is actually the at91sam9263ek_dataflash_c0 version in which only the main clock frequency has been patched. I therefore propose to give the at91sam9263ek_dataflash_c0 version a shot and see how far I will come. Hope this is ok.
Cheers Uli

-----Original Message-----
From: Reinhard Meyer [mailto:u-boot at emk-elektronik.de] 
Sent: Tuesday, February 08, 2011 5:43 PM
To: Uli Raich; u-boot
Subject: Re: [STATUS: AT91/AVR32]

Dear Uli Raich,


1. please *always* reply to the list as well

2. Makefile is not relevant for new/fixed boards anymore.
New/fixed boards are added to boards.cfg (and have to be removed from Makefile)!

3. *ONLY* at91sam9260/9xeek are known to work! at91sam9263ek definitely is not working yet,
patches are in the pipeline.

Best Regards,
Reinhard