[U-Boot] [STATUS: AT91/AVR32]
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 :)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Dear Uli Raich,
Quoted 4 lines
Dear Reinhard,
Many thanks for your answer. Only... I do not find a at91sam9260ek in thisMakefile. 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
Hi Reinhard,
2011/2/8 Reinhard Meyer <[email protected]>:
Quoted 5 lines
Dear Uli Raich,
Quoted 4 lines
Dear Reinhard,
Many thanks for your answer. Only... I do not find a at91sam9260ek in thisMakefile. I find at91sam9261ek or ?at91sam92603ek though. Will try the at91sam92603ek config.
Uli
Quoted 7 lines
1. please *always* reply to the list as well
2.
Makefileis not relevant for new/fixed boards anymore.
New/fixed boards are added to boards.cfg (and have to be removed fromMakefile)!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
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
Am 08.02.2011 16:35, schrieb Reinhard Meyer:
Quoted 9 lines
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
Dear Jens Scharsig,
Am 08.02.2011 um 22:11 schrieb Jens Scharsig:
Quoted 14 lines
Am 08.02.2011 16:35, schrieb Reinhard Meyer:
Quoted 9 lines
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_cpux9k2board and if you now do the soc rework 2009.
Quoted 7 lines
Currently the arm920t/at91 are not touched by your rework.
I can try to update the
at91rm9200.hto theatmel_xxxxname 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 ...
Quoted 2 lines
A second problem is, both boards use the legacy at91rm9200 usart driver. So we could try to use the
atmel_usartin 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