Re: [U-Boot] [PATCH] Disable FLASH_AMLV256U support for TOP860 target
Am 28.10.2014 10:48, schrieb Wolfgang Denk:
Dear Reinhard,
In message ca+gzxspktwyahhm88fbtgw17cxt7ncez9obxwpqij55wr-k...@mail.gmail.com
Vasili Galka wrote:
You're right, that would probably be a better solution. Although I'm not a
user of TOP860 board so I'm not really the right person to ask...
I just found this bug theoretically from looking on compiler warnings and
suggested a possible solution.
Best,
Vasili
On Tue, Oct 28, 2014 at 11:33 AM, Wolfgang Denk w...@denx.de wrote:
Dear Vasili,
In message CA+gZxsOYLBU18LimMmfP9B-gZaykN=
hztm1fvgpd8p-eew1...@mail.gmail.com you wrote:
TOP860 configuration assumes at most 128 flash sectors. Thus, the
AMLV256U flash can't be supported. The existing code could result in
memory corruption when writing to the flash_info-start[] array.
Signed-off-by: Vasili Galka vvv...@gmail.com
Cc: Wolfgang Denk w...@denx.de
---
board/emk/common/flash.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/board/emk/common/flash.c b/board/emk/common/flash.c
index ae5777c..4119b3b 100644
--- a/board/emk/common/flash.c
+++ b/board/emk/common/flash.c
@@ -324,6 +324,7 @@ ulong flash_get_size (FPWV *addr, flash_info_t
*info)
}
break;
}
+#ifndef CONFIG_TOP860
if ((FPW)addr[FLASH_ID3] == (FPW)AMD_ID_LV256U_2
(FPW)addr[FLASH_ID4] == (FPW)AMD_ID_LV256U_3)
{
@@ -337,7 +338,8 @@ ulong flash_get_size (FPWV *addr, flash_info_t
*info)
}
break;
}
-
+#endif
+
/* fall thru to here ! */
default:
printf (unknown AMD device=%x %x %x,
--
1.7.9
Any review?
This was inspired by a a compiler warning. I'm still getting this warning
on the latest master.
Sorry, I missed that one.
Would it not be more appropriate to adjust the CONFIG_SYS_MAX_FLASH_SECT
setting in include/configs/TOP860.h? Or are you 100% sure that
there were never be any AMLV256U flash chips fit on a TOP860 board?
Maybe you can comment?
Or is the TOP860 board so obsolete that we can remove it alltogether?
What about the other boards in board/emk ? I don't see any real
changes there during the last 5 years or so? Are these still
actively maintained?
Best regards,
Wolfgang Denk
Dear Wolfgang,
top860 can be removed (We already had that discussion a while ago.)
top5200 is still active in several older projects, but there was no need
to make changes to u-boot or to integrate new features of u-boot.
Therefore I am not testing whether any changes to u-boot break the
function of top5200.
top9000 is dead. Thanks atmel :(
However it might be left in u-boot as an example.
Best regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Disable FLASH_AMLV256U support for TOP860 target
Dear Wolfgang, Dear Reinhard, In message 544f6ad8.2070...@emk-elektronik.de you wrote: top860 can be removed (We already had that discussion a while ago.) top5200 is still active in several older projects, but there was no need to make changes to u-boot or to integrate new features of u-boot. Therefore I am not testing whether any changes to u-boot break the function of top5200. top9000 is dead. Thanks atmel :( However it might be left in u-boot as an example. Hm... if two of the boards are dead, and you are not even testing the third, can we not just remove all of them? That would also allow to get rid of board/emk/common: Agreed. - am79c874.c is completely bogus anyway How so? - flash.c should have been replaced by the CFI driver years ago I think there was/is an issue with the fact that top5200 uses GPIO for the uppermost (A16+) address lines AND that FLASH is connected 8 Bit wide. Maybe CFI code does support such by now, at that time it did not. - vpd.c is causing efforts when I2C / EEPROM code gets changed ideally, the API should not change that often ;) What do you think? Since its quite unlikely I will make any changes to those boards in the future, they can be removed. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bug in TOP860 code with gcc 4.8.1
Hello Jeroen, Hello Reinhard, On 01/14/2014 12:33 PM, Reinhard Meyer wrote: Dear Wolfgang, Dear Reinhard, attempting to build the TOP860 code with a GCC 4.8.1 based tool chain (say ELDK v5.5 or Yocto 1.5) gives the following errors: - ./MAKEALL TOP860 Configuring for TOP860 board... textdata bss dec hex filename 165471 21020 17316 203807 31c1f ./u-boot ../common/flash.c: In function 'flash_init': ../common/flash.c:336:20: warning: iteration 128u invokes undefined behavior [-Waggressive-loop-optimizations] info-start[i] = (ulong)addr + 0x1 * i; ^ ../common/flash.c:334:4: note: containing loop for (i = 0; i info-sector_count; i++) ^ ... Can you please provide a fix - or is this old hardware and the code should be removed from the U-Boot tree? 1. on first and second glance I cannot see where this (simple!!) loop might invoke undefined behaviour. Seems like a compiler/optimizer bug to me... 2. should not the same issue arise with TOP5200 (using the same flash.c) ?? 3. nevertheless TOP860 can be removed. It is out of bounds: include/configs/TOP860.h:#define CONFIG_SYS_MAX_FLASH_SECT128 /* max number of sectors on one chip*/ include/configs/TOP5200.h:#define CONFIG_SYS_MAX_FLASH_SECT 256 /* max num of sects on one chip */ Removing will work as well of course ;) Regards, Jeroen I see. Because of the common code with TOP5200, there is potentially a larger flash chip available in the switch, which would cause undefined behaviour later. However TOP860 has never seen more than 2MB of flash :) so there is no actual danger. For the next few weeks I do not have the capacity to provide a patch, and since the TOP860 U-Boot is frozen to a very old state by the customers anyway, it is save to be removed from the current tree. Best Regards Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bug in TOP860 code with gcc 4.8.1
Dear Wolfgang, Dear Reinhard, attempting to build the TOP860 code with a GCC 4.8.1 based tool chain (say ELDK v5.5 or Yocto 1.5) gives the following errors: - ./MAKEALL TOP860 Configuring for TOP860 board... textdata bss dec hex filename 165471 21020 17316 203807 31c1f ./u-boot ../common/flash.c: In function 'flash_init': ../common/flash.c:336:20: warning: iteration 128u invokes undefined behavior [-Waggressive-loop-optimizations] info-start[i] = (ulong)addr + 0x1 * i; ^ ../common/flash.c:334:4: note: containing loop for (i = 0; i info-sector_count; i++) ^ ... Can you please provide a fix - or is this old hardware and the code should be removed from the U-Boot tree? 1. on first and second glance I cannot see where this (simple!!) loop might invoke undefined behaviour. Seems like a compiler/optimizer bug to me... 2. should not the same issue arise with TOP5200 (using the same flash.c) ?? 3. nevertheless TOP860 can be removed. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91: Add support for Bluewater Systems Snapper 9G45 module
Dear Simon Glass,
Snapper 9G45 is a ARM9-based CPU module with 1GB NAND and 128MB
DDR SDRAM. This patch includes NAND and Ethernet support.
Signed-off-by: Simon Glasssgl...@bluewatersys.com
---
board/bluewater/snapper9g45/Makefile | 43 +++
board/bluewater/snapper9g45/snapper9g45.c | 155 +++
boards.cfg|1 +
include/configs/snapper9g45.h | 189
+
4 files changed, 388 insertions(+), 0 deletions(-)
create mode 100644 board/bluewater/snapper9g45/Makefile
create mode 100644 board/bluewater/snapper9g45/snapper9g45.c
create mode 100644 include/configs/snapper9g45.h
[...]
+
+#ifndef NEW
+#define CONFIG_PCA953X
+#define CONFIG_SYS_I2C_PCA953X_ADDR 0x28
+#define CONFIG_SYS_I2C_PCA953X_WIDTH { {0x28, 16} }
+#endif
if that is a board variant, use something better than just NEW -
and where would that ever get defined?
+/* Command line configuration */
+#includeconfig_cmd_default.h
Space missing here.
Please run checkpatch before submitting!
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/10] Add getenv_ulong to return an environment var as a number
Dear Simon Glass, Several places in U-Boot's board files can make use of a function like this, so this patch series creates the function, and changes the board files to use it. As suggested by Mike Frysingervap...@gentoo.org. Simon Glass (10): Add getenv_int() to read an integer from an environment variable Just a question (I cannot dig deep into this): Since getenv_* might be used before relocation (it is for baudrate, am I right?), and I cannot see how getenv_int() would work before relocation. And why do you mention getenv_int but implement getenv_long? Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32: fix timer_init() return type
Dear Andreas Bießmann, if (set_interrupt_handler(0, timer_interrupt_handler, 3)) -return; +return 0; NAK, this is an error and should return a negative value (though the return value is currently not evaluated). Agreed BTW there is another patch pending - http://patchwork.ozlabs.org/patch/117688/ I'll apply that one in the year 2015 ;) NO.. its on my list for applying into next Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AVR32: switch to generic mmc framework
Dear Sven Schnelle, Hi List, these patches switch all AVR32 boards to the generic MMC framework. Motivation for doing so is to be able to boot from SDHC cards. The second patch removes the legacy atmel_mci driver, as it is no longer used by any board. I've only tried this code on the Atmel ATNGW100, as i have no other AVR32 boards. Would be great if some other users could try that patch on different platforms. It seems like the gen_atmel_mci driver doesn't work with Multible Block transfer on AVR32, but the old code didn't used that mode either. So that's something for the TODO list for future improvements. 1. your patch title is misleading, because it also affects the AT91 architecture. use AVR32 when patches affect avr32 only use AT91 when patches affect at91 only use ATMEL when patches affect generic Atmel stuff 2. you should use the git rename feature to rename files As I see it, all this should come as three patches: 1. switching *all* AVR32 and AT91 boards to use the *existing* generic driver 2. removal of the now obsolete legacy driver 3. renaming the existing generic driver into the old legacy name (this is a pure cosmetic act) I would tend to dispute whether 3. is really necessary and beneficial Best Regards Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91rm9200ek.h: explicitly disable D-Cache
Dear Andreas Bießmann, Commit c2dd0d45540397704de9b13287417d21049d34c6 enabled D-Cache for all arm devices explicitly. This renders at91_emac driver on at91rm9200ek unusable. This patch disables D-Cache for at91rm9200ek explicitly to get this driver working again. As my experience, the MACB driver does work with dcache enabled. What are the reasons again that MACB and AT91_EMAC do coexist for the same SoC-IP ? Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] ARM: board removal
Dear Albert, [snip] Also, the following boards, for which Reinhard is a delegate, are still undecided: [U-Boot,46/52] ARM: remove broken at91rm9200dk board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,45/52] ARM: remove broken m501sk board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,44/52] ARM: remove broken kb9202 board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,43/52] ARM: remove broken csb637 board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,42/52] ARM: remove broken cmc_pu2 board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,40/52] ARM: remove broken at91cap9adk board 2011-07-17 Wolfgang Denk reinhardm New Reinhard, can you either let me know if these should be removed or kept (or if you're going to process them through your repo and send out a pull req)? If you are in the routine of applying removal patches, remove them as well. I have not heard anything about those boards. Thank you! Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] d-cache enable
Dear *ALL*, It is embarrassing to admit, but I've __wrongly__ assumed that *_range() functions are accepting the start address and range for invalidation/flushing. Do you mean we're hitting again a confusion between *_range(start, stop) and *_range(start, length)? If so, then the need to get rid of 'anonymous prototypes' becomes greater yet. Maybe the parameters should even be of type (void *start, void *beyond_end) ? We are talking of addresses here anyway. Most likely the calling place has it as pointer, and inside the function it might have to be casted. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AT91: fix at91cap9 SoC files
Dear Albert, Signed-off-by: Reinhard Meyeru-b...@emk-elektronik.de --- FYI, there are two consecutive commits in your u-boot-atmel/fix-at91cap9 branch with this same exact title of AT91: fix at91cap9 SoC files. Somehow this can't be correct: either both patches contribute to the same atomic change and should be merged under their common title, or they do different things and their titles do not reflex what they each do. I tried to provide a fix myself, but that is imcomplete. I am waiting on SOMEONE ELSE to continue this fix effort, or to provide a complete new one... At the end *ALL* would be merged into one patch, of course. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] relocation problem
Dear Cajus Hahn, Dear Marcel, Dear Reinhard, I have the same problem with my board and the actual u-boot-atmel (git from 5th Aug. 2011). It even looks like I am using the same board. It is a in-circuit ICnova SAM9G45 OEM on a ADB1000 with a 5 display. Actually I use the u-boot from in-circuit, which is a patched version basing on u-boot from 2009. I would like to upgrade this old version to the actual u-boot version. Some time ago somebody tried to get the in-circuit patch into the u-boot mainstream, but the patch was rejected because of not meeting the coding rules. Marcel, can you give me a hint what you changed to get your configuration running ? I used the latest code for the at91sam9m10g45ek as reference and added/changed it. First, let me clear up a thing: Most ARM boards were runtime broken when relocation was introduced. We additionally broke the AT91 boards by cleaning up the SoC header and source files. This second brokenness has been removed by the recent patches for most of the AT91 SoCs. What probably has not been fixed in all cases is the brokeness due to the relocation. It might well be, that boards build clean, but might not run beyond relocation. You probably have such an issue. Please refer to the doc/README.ARM-relocation. Make sure TEXT_BASE is exactly the address where at91bootstrap loads u-boot. Make sure that at91bootstrap loads the full u-boot image (u-boot became larger quite a bit due to relocation and other changes). Make sure that area is not overlapping the final location of the relocated u-boot (top of RAM). The default at91bootstraps tend to load the image already quite high into RAM, if relocation overlaps this, you are doomed. Starting the old u-boot version with patches from in-circuit: - Start AT91Bootstrap U-Boot 2009.11 (Jun 18 2011 - 19:57:09) DRAM: 128 MB Flash: 1 MB NAND: 256 MiB In:serial Out: serial Err: serial MMC: Atmel MCI: 0 Net: macb0 Hit any key to stop autoboot: 0 ICnova Starting u-boot-atmel (git) from 5th Aug. 2011: Start AT91Bootstrap U-Boot 2011.06 (Aug 10 2011 - 20:49:32) U-Boot code: 73F0 - 73F45494 BSS: - 73F87110 I do not see any TEXT_BASE definition in the files below. Have you merged current u-boot with some old patches? CPU: AT91SAM9G45 Crystal frequency: 12 MHz CPU clock: 400 MHz Master clock : 133.333 MHz monitor len: 00087110 ramsize: 0800 TLB table at: 77ff Top of RAM usable for U-Boot at: 77ff Reserving 540k for U-Boot at: 77f68000 Reserving 384k for malloc() at: 77f08000 Reserving 24 Bytes for Board Info at: 77f07fe8 Reserving 144 Bytes for Global Data at: 77f07f58 New Stack Pointer is: 77f07f48 RAM Configuration: Bank #0: 7000 128 MiB relocation Offset is: 04068000 no more output, it seems the relocation fails. I have a #DEBUG in lib/board.c to get the above output. Here is my configuration: /* * Configuation settings for the ICNOVA ADB1000 with SAM9G45 OEM and 5 TFT. * * 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 */ #ifndef __CONFIG_H #define __CONFIG_H #include asm/hardware.h Where is the definition that an AT91SAM9G45 is used? It MUST BE defined before hardware.h is included. #define CONFIG_AT91_LEGACY #define CONFIG_ATMEL_LEGACY /* required until (g)pio is fixed */ /* ARM asynchronous clock */ #define CONFIG_SYS_AT91_SLOW_CLOCK 32768 #define CONFIG_SYS_AT91_MAIN_CLOCK 1200 /* from 12 MHz crystal */ #define CONFIG_SYS_HZ 1000 #define CONFIG_AT91FAMILY #define CONFIG_ARCH_CPU_INIT #undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */ #define CONFIG_CMDLINE_TAG/* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_INITRD_TAG #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_DISPLAY_CPUINFO /* general purpose I/O */ #define CONFIG_ATMEL_LEGACY /* required until (g)pio is fixed */ #define CONFIG_AT91_GPIO #define CONFIG_AT91_GPIO_PULLUP 1 /*
Re: [U-Boot] relocation problem (again)
Dear Cajus Hahn, Dear Marcel, Dear Reinhard, sorry I forgot to mention, that this is in reply to http://lists.denx.de/pipermail/u-boot/2011-January/084499.html I suppose you have not followed the steps I pointed out then? I have the same problem with my board and the actual u-boot-atmel (git ... Please do not repeat the same message. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Dear Albert, Aneesh, Hong, There seem to be functions of type xxx(start, end) and xxx(start, size). Can't it be somehow decided to use only one variant in all cases (flush, invalidate)? On a personal taste, I'd prefer (start, size) :) Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Hi Aneesh, On Monday 08 August 2011 03:29 PM, Reinhard Meyer wrote: Dear Albert, Aneesh, Hong, There seem to be functions of type xxx(start, end) and xxx(start, size). Can't it be somehow decided to use only one variant in all cases (flush, invalidate)? The u-boot standard seems to be xxx(start, end) where the operation will be done on the range [start, end). This is what I figured out by looking at the prototypes and existing implementations when I did the armv7 work and I have stuck to this standard. Hong also seems to be following the same standard. If there is no objection, I shall add this definition to the README I am adding. Maybe its arch specific, I just saw this in another thread, thats why I asked: +++ b/arch/mips/cpu/mips32/cpu.c @@ -52,6 +52,11 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) void flush_cache(ulong start_addr, ulong size) Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Dear Albert, Aneesh, Eric, We have a fundamental problem when it comes to invalidating an un-aligned buffer. Either you flush the boundary lines and corrupt your buffer at boundaries OR you invalidate without flushing and corrupt memory around your buffer. Both are not good! The only real solution is to have aligned buffers, if you want to have D-cache enabled and do DMA at the same time. Plus, there should not be *heavy* modifications; DMA engines tend to use essentially two types of memory-resident objects: data buffers and buffer descriptors. There's only a small handful of places in the driver code to look at to find where these objects are allocated and how. So I stand by my opinion: since the cache invalidation routine should only be called with cache-aligned objects, there is no requirement to flush the first (resp. last) cache line in case of unaligned start (resp.stop), and I don't want cache operations performed when they are not required. After considering all issues, any driver that does flush OR invalidate a cache line that it does not fully own is prone to cause problems. At flushing: some DMA might just have put data into the partial line. At invalidating: some Software might have put data, but the writeback had not occured. So both flush AND invalidate functions should check for this event and emit a proper warning on the console. My 2.7 cents... Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [MAKEALL arm] gcc 4.5.2/32 bit - 99 of 204 broken (was:Re: Pull request: u-boot-arm/master -- updated)
Dear Albert, Since this is an ARM question, I'll look into it, and since Wolfgang will be on vacation, I suggest either that we either postpone -rc1, or (preferably IMO) that we tag -rc1 now with a specific warning about the ARM tree, and I analyze what the issue is using several ARM toolchains, both on a 32 and a 64 bits system, with a resolution on -rc2. I think the resolution should be fast because on a 32-bit system (sorry, don't have one any more, will keep a VM somewhere from now on...) the failure rate is 100%, thus I should be able to quickly set up a 32-bit VM and ELDK 4.2 and pinpoint the issue, say during the week-end. This is my results of MAKEALL arm on current u-boot-arm/master (6623feeaa463f5931fe684f900f605999cd844e2 Merge remote-tracking branch 'u-boot-atmel/master' into m): - SUMMARY Boards compiled: 204 Boards with warnings or errors: 99 ( assabet dnp1110 gcplus lart shannon ap7 ap720t armadillo B2 ep7312 evb4510 impa7 integratorap lpc2292sodimm modnet50 SMN42 ap920t ap922_XA10 ap926ejs ap946es ap966 cp920t cp922_XA10 cp926ejs cp946es cp966 edb9301 edb9302 edb9302a edb9307 edb9307a edb9312 edb9315 edb9315a edminiv2 guruplug jadecpu km_kirkwood lpd7a400 mv88f6281gtw_ge mx1fs2 netstar openrd_base openrd_client openrd_ultimate portl2 rd6281a sbc2410x scb9328 sheevaplug smdk2400 smdk2410 spear300 spear310 spear320 spear600 VCMA9 versatile versatileab versatilepb voiceblue integratorcp cp1026 cp1136 omap2420h4 apollon imx31_litekit imx31_phycore imx31_phycore_eet mx31ads mx31pdk mx31pdk_nand qong smdk6400 dig297 igep0020 mx51evk omap3_beagle omap3_overo omap3_evm omap3_zoom2 omap4_panda omap4_sdp4430 at91cap9adk csb226 lubbock zylonite actux1_4_16 actux1_8_16 actux1_4_32 actux1_8_32 actux2 actux3 actux4 dvlhost ixdp425 ixdpg425 pdnb3 scpu ) -- Toolchain: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.5.2-8ubuntu3) 4.5.2 on ubuntu 11.04 in virtual machine (VMware) on WinXP (32 Bit) Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MAKEALL ARM: Use boards.cfg
Dear Dirk Behme, From: Dirk Behme dirk.be...@googlemail.com Use the boards from boards.cfg for building ./MAKEALL ARMx. Note: ARM10 systems don't seem to exist any more. Wrong: a simple grep shows that those are still in Makefile. Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- Changes in v2: Instead of dublicating the missing boards from boards.cfg to MAKEALL, use the boards defined in boards.cfg directly. This sentence does not make sense to me... How can something that is missing be duplicated? I think you were wanting to say: remove all boards that are in boards.cfg from MAKEALL MAKEALL | 134 1 file changed, 9 insertions(+), 125 deletions(-) Are all those boards removed here in boards.cfg? Answer: NO Are none of them still in Makefile? Answer: NO Remember: 1. boards must either be in Makefile OR boards.cfg 2. boards that are still in Makefile MUST BE in MAKEALL 3. boards that are in boards.cfg SHOULD NOT be in MAKEALL Of the boards removed from MAKEALL by your patch, I found several in Makefile but not in boards.cfg. By removing them from MAKEALL they will not be built any more in MAKEALL runs and this would hide their possible brokenness! Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91: reworked support for meesc board
Dear Matthias Fuchs, The meesc board support was broken. Within this opportunity, I completely reworked the board files. Signed-off-by: Daniel Gorsulowski daniel.gorsulow...@esd.eu Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- V3: -fix white space issues and don't patch boards.cfg V2: -fixed commit description board/esd/meesc/config.mk |1 - board/esd/meesc/meesc.c | 49 ++- include/configs/meesc.h | 208 ++--- 3 files changed, 147 insertions(+), 111 deletions(-) delete mode 100644 board/esd/meesc/config.mk Sorry, this patch had escaped my sight. Checkpatch has the following issues: WARNING: Use #include linux/io.h instead of asm/io.h #53: FILE: board/esd/meesc/meesc.c:30: +#include asm/io.h -- ignored WARNING: please, no space for starting a line, excluding comments #334: FILE: include/configs/meesc.h:134: + /* DataFlash */$ -- fixed before applying ERROR: Macros with complex values should be enclosed in parenthesis #369: FILE: include/configs/meesc.h:157: +# define CONFIG_SYS_NAND_ENABLE_PINAT91_PIO_PORTD, 15 ERROR: Macros with complex values should be enclosed in parenthesis #370: FILE: include/configs/meesc.h:158: +# define CONFIG_SYS_NAND_READY_PIN AT91_PIO_PORTA, 22 -- both not nice style, but understandable als long as gpio routines have 2 parameters (port and bit). Configuring for meesc - Board: meesc, Options: AT91SAM9263,SYS_USE_NANDFLASH textdata bss dec hex filename 2014345304 74688 281426 44b52 ./u-boot Configuring for meesc_dataflash - Board: meesc, Options: AT91SAM9263,SYS_USE_DATAFLASH textdata bss dec hex filename 2073035472 75096 287871 4647f ./u-boot [U-Boot,41/52] ARM: remove broken meesc board set to not applicable Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] atmel: update at91sam9m10g45 SoC support to new style
Dear Thomas Petazzoni, Based on earlier work by Alex Waterman awater...@dawning.com. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- .../cpu/arm926ejs/at91/at91sam9m10g45_devices.c| 28 ++-- arch/arm/include/asm/arch-at91/at91sam9g45.h | 12 ++ .../arm/include/asm/arch-at91/at91sam9g45_matrix.h | 194 +++- 3 files changed, 94 insertions(+), 140 deletions(-) This patch still has the same issues I complained about at http://patchwork.ozlabs.org/patch/102811/ please fix them. Also your *_matrix.h is space corrupted (indentation done by space not tab). Tabs must be used! Please, and again, refer to the templates done in the 926x SoCs. WARNING: please, no space for starting a line, excluding comments #184: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:21: + u32 mcfg[16];$ WARNING: please, no space for starting a line, excluding comments #185: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:22: + u32 scfg[16];$ WARNING: please, no space for starting a line, excluding comments #186: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:23: + u32 pras[16][2];$ WARNING: please, no space for starting a line, excluding comments #187: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:24: + u32 mrcr; /* 0x100 Master Remap Control */$ WARNING: please, no space for starting a line, excluding comments #188: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:25: + u32 filler[3];$ WARNING: please, no space for starting a line, excluding comments #189: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:26: + u32 tcmr;$ WARNING: please, no space for starting a line, excluding comments #190: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:27: + u32 filler2;$ WARNING: please, no space for starting a line, excluding comments #191: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:28: + u32 ddrmpr;$ WARNING: please, no space for starting a line, excluding comments #192: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:29: + u32 filler3[3];$ WARNING: please, no space for starting a line, excluding comments #193: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:30: + u32 ebicsa;$ WARNING: please, no space for starting a line, excluding comments #194: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:31: + u32 filler4[47];$ WARNING: please, no space for starting a line, excluding comments #195: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:32: + u32 wpmr;$ WARNING: please, no space for starting a line, excluding comments #196: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:33: + u32 wpsr;$ WARNING: line over 80 characters #315: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:66: +#define AT91_MATRIX_RCB0(1 0)/* Remap Command for AHB Master 0 (ARM926EJ-S Instruction Master) */ WARNING: line over 80 characters #316: FILE: arch/arm/include/asm/arch-at91/at91sam9g45_matrix.h:67: +#define AT91_MATRIX_RCB1(1 1)/* Remap Command for AHB Master 1 (ARM926EJ-S Data Master) */ total: 0 errors, 15 warnings, 312 lines checked U-Boot-1-2-atmel-update-at91sam9m10g45-SoC-support-to-new-style.patch has style problems, please review. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] atmel: Update support of board AT91SAM9M10G45-EK to new style
Dear Thomas Petazzoni,
Based on earlier work by Alex Waterman awater...@dawning.com.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
Makefile| 21 ---
board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 121 +---
board/atmel/at91sam9m10g45ek/led.c |6 +-
boards.cfg |1 +
include/configs/at91sam9m10g45ek.h | 187
+++
5 files changed, 160 insertions(+), 176 deletions(-)
First, the checkpatch complaints:
WARNING: Use #include linux/io.h instead of asm/io.h
#67: FILE: board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c:26:
+#include asm/io.h
-- ignore this
ERROR: (foo*) should be (foo *)
#284: FILE: board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c:291:
+ gd-ram_size = get_ram_size((void*) CONFIG_SYS_SDRAM_BASE,
WARNING: externs should be avoided in .c files
#303: FILE: board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c:347:
+extern void at91_serial_hw_init(void);
-- you need to call at91_seriald_hw_init() anyway!
WARNING: Use #include linux/io.h instead of asm/io.h
#322: FILE: board/atmel/at91sam9m10g45ek/led.c:26:
+#include asm/io.h
-- ignore this
WARNING: please, no space for starting a line,
excluding comments
#498: FILE: include/configs/at91sam9m10g45ek.h:128:
+ (CONFIG_SYS_SDRAM_BASE + 4 * 1024 - GENERATED_GBL_DATA_SIZE)$
total: 1 errors, 4 warnings, 550 lines checked
U-Boot-2-2-atmel-Update-support-of-board-AT91SAM9M10G45-EK-to-new-style.patch
has style problems, please review.
diff --git a/board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c
b/board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c
index f92b20f..40ee345 100644
--- a/board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c
+++ b/board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c
@@ -23,17 +23,14 @@
*/
#include common.h
-#include asm/sizes.h
-#include asm/arch/at91sam9g45.h
-#include asm/arch/at91sam9_matrix.h
+#include asm/io.h
+#include asm/arch/at91sam9g45_matrix.h
#include asm/arch/at91sam9_smc.h
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
#include asm/arch/at91_rstc.h
-#include asm/arch/clk.h
#include asm/arch/gpio.h
-#include asm/arch/io.h
-#include asm/arch/hardware.h
+#include asm/arch/clk.h
#include lcd.h
#include atmel_lcdc.h
#if defined(CONFIG_RESET_PHY_R) defined(CONFIG_MACB)
@@ -49,35 +46,38 @@ DECLARE_GLOBAL_DATA_PTR;
*/
#ifdef CONFIG_CMD_NAND
-static void at91sam9m10g45ek_nand_hw_init(void)
+void at91sam9m10g45ek_nand_hw_init(void)
{
+ struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
+ struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX;
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
unsigned long csa;
/* Enable CS3 */
- csa = at91_sys_read(AT91_MATRIX_EBICSA);
- at91_sys_write(AT91_MATRIX_EBICSA,
-csa | AT91_MATRIX_EBI_CS3A_SMC_SMARTMEDIA);
+ csa = readl(matrix-ebicsa);
+ csa |= AT91_MATRIX_EBI_CS3A_SMC_SMARTMEDIA;
+ writel(csa, matrix-ebicsa);
/* Configure SMC CS3 for NAND/SmartMedia */
- at91_sys_write(AT91_SMC_SETUP(3),
-AT91_SMC_NWESETUP_(1) | AT91_SMC_NCS_WRSETUP_(0) |
-AT91_SMC_NRDSETUP_(1) | AT91_SMC_NCS_RDSETUP_(0));
- at91_sys_write(AT91_SMC_PULSE(3),
-AT91_SMC_NWEPULSE_(4) | AT91_SMC_NCS_WRPULSE_(3) |
-AT91_SMC_NRDPULSE_(3) | AT91_SMC_NCS_RDPULSE_(2));
- at91_sys_write(AT91_SMC_CYCLE(3),
-AT91_SMC_NWECYCLE_(7) | AT91_SMC_NRDCYCLE_(4));
- at91_sys_write(AT91_SMC_MODE(3),
-AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
-AT91_SMC_EXNWMODE_DISABLE |
+ writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+smc-cs[3].setup);
+ writel(AT91_SMC_PULSE_NWE(4) | AT91_SMC_PULSE_NCS_WR(3) |
+AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(2),
+smc-cs[3].pulse);
+ writel(AT91_SMC_CYCLE_NWE(7) | AT91_SMC_CYCLE_NRD(4),
+smc-cs[3].cycle);
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+AT91_SMC_MODE_EXNW_DISABLE |
#ifdef CONFIG_SYS_NAND_DBW_16
-AT91_SMC_DBW_16 |
+AT91_SMC_MODE_DBW_16 |
#else /* CONFIG_SYS_NAND_DBW_8 */
-AT91_SMC_DBW_8 |
+AT91_SMC_MODE_DBW_8 |
#endif
-AT91_SMC_TDF_(3));
+AT91_SMC_MODE_TDF_CYCLE(3),
+smc-cs[3].mode);
- at91_sys_write(AT91_PMC_PCER, 1 AT91SAM9G45_ID_PIOC);
+ writel(1 ATMEL_ID_PIOC, pmc-pcer);
/* Configure RDY/BSY */
at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
@@ -90,7 +90,9 @@ static void at91sam9m10g45ek_nand_hw_init(void)
#ifdef
Re: [U-Boot] [PATCH] sbc35_a9g20: update board to the new AT91 organization
Dear Thomas Petazzoni, Cc: Albin Tonnerre tonnerreal...@gmail.com CC: Gregory Hermant gregory.herm...@calao-systems.com Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- Makefile |7 --- board/calao/sbc35_a9g20/sbc35_a9g20.c | 88 + boards.cfg|2 + include/configs/sbc35_a9g20.h | 87 +++- 4 files changed, 88 insertions(+), 96 deletions(-) I had to fix two issues: ERROR: (foo*) should be (foo *) #200: FILE: board/calao/sbc35_a9g20/sbc35_a9g20.c:174: + (void*)CONFIG_SYS_SDRAM_BASE, Added removal of SBC35_9G20 from MAKEALL. Configuring for sbc35_a9g20_nandflash - Board: sbc35_a9g20, Options: AT91SAM9G20,SYS_USE_NANDFLASH textdata bss dec hex filename 1961365980 267224 469340 7295c ./u-boot Configuring for sbc35_a9g20_eeprom - Board: sbc35_a9g20, Options: AT91SAM9G20,SYS_USE_EEPROM textdata bss dec hex filename 1949845984 267244 468212 724f4 ./u-boot Removal Patch for this board set to Non Applicable. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tny_a9260/tny_a9g20: update board to the new AT91 organization
Dear Thomas Petazzoni, Cc: Albin Tonnerre tonnerreal...@gmail.com CC: Gregory Hermant gregory.herm...@calao-systems.com Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- board/calao/tny_a9260/tny_a9260.c | 55 boards.cfg|4 ++ include/configs/tny_a9260.h | 85 ++--- 3 files changed, 73 insertions(+), 71 deletions(-) I had to manually add the removal of those board(s) from Makefile and MAKEALL. Please be more careful next time :) Configuring for tny_a9260_nandflash - Board: tny_a9260, Options: AT91SAM9260,SYS_USE_NANDFLASH textdata bss dec hex filename 1337525624 204592 343968 53fa0 ./u-boot Configuring for tny_a9260_eeprom - Board: tny_a9260, Options: AT91SAM9260,SYS_USE_EEPROM textdata bss dec hex filename 1337525624 204592 343968 53fa0 ./u-boot Configuring for tny_a9g20_nandflash - Board: tny_a9260, Options: AT91SAM9G20,SYS_USE_NANDFLASH textdata bss dec hex filename 1337765624 204592 343992 53fb8 ./u-boot Configuring for tny_a9g20_eeprom - Board: tny_a9260, Options: AT91SAM9G20,SYS_USE_EEPROM textdata bss dec hex filename 1337765624 204592 343992 53fb8 ./u-boot - SUMMARY Boards compiled: 4 -- Removal patch for those boards set to Not Applicable. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, AT91, rework] pm9261: compiles with the AT91 reworked scheme
Dear Asen Dimov, oddly I don't have the original e-Mail im my Inbox, but the patch was in patchwork: Signed-off-by: Asen Chavdarov Dimov di...@ronetix.at --- Note: This patch was a part of patches, but it is better to be done step by step and so this patch is a split from the patch series with message id: 1307606409-29818-3-git-send-email-di...@ronetix.at and Patchwork: http://patchwork.ozlabs.org/patch/99666/ Changes for v2: - rename at91_serial_hw_init() to at91_seriald_hw_init() checkpatch complains at board/ronetix/pm9261/pm9261.c:148, but checkpatch could be mistaken. board/ronetix/pm9261/led.c|9 - board/ronetix/pm9261/pm9261.c | 38 ++ boards.cfg|2 +- include/configs/pm9261.h | 18 ++ 4 files changed, 33 insertions(+), 34 deletions(-) Applied cleanly, Configuring for pm9261 - Board: pm9261, Options: AT91SAM9261 textdata bss dec hex filename 211233 10948 72416 294597 47ec5 ./u-boot Board removal for pm9261 marked Non Applicable. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] atmel: update at91sam9m10g45 SoC support to new style
Dear Thomas Petazzoni, Based on earlier work by Alex Waterman awater...@dawning.com. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- .../cpu/arm926ejs/at91/at91sam9m10g45_devices.c| 114 ++-- arch/arm/include/asm/arch-at91/at91sam9g45.h | 12 ++ .../arm/include/asm/arch-at91/at91sam9g45_matrix.h | 194 +++- 3 files changed, 135 insertions(+), 185 deletions(-) Applied to u-boot-atmel/master, Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] atmel: Update support of board AT91SAM9M10G45-EK to new style
Dear Thomas Petazzoni, Based on earlier work by Alex Waterman awater...@dawning.com. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- Makefile| 21 --- board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 114 +++-- board/atmel/at91sam9m10g45ek/led.c |6 +- boards.cfg |1 + include/configs/at91sam9m10g45ek.h | 193 ++- 5 files changed, 154 insertions(+), 181 deletions(-) Removal of board from MAKEALL missing... Configuring for at91sam9m10g45ek_nandflash - Board: at91sam9m10g45ek, Options: AT91SAM9M10G45,SYS_USE_NANDFLASH at91sam9m10g45ek.c: In function ‘board_early_init_f’: at91sam9m10g45ek.c:256:1: warning: control reaches end of non-void function textdata bss dec hex filename 201534 32116 71760 305410 4a902 ./u-boot AND this board's early_init_f is quite different from the other atmel boards, also the place of calling at91_seriald_hw_init() is different from them. Please verify that this is OK. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][AT91 rework 1/1] make pm9263 buildable for v2011.06 release
Dear Asen Dimov, Signed-off-by: Asen Chavdarov Dimov di...@ronetix.at --- board/ronetix/pm9263/led.c|9 +++ board/ronetix/pm9263/pm9263.c | 42 +++- boards.cfg|2 +- include/configs/pm9263.h | 17 +-- 4 files changed, 35 insertions(+), 35 deletions(-) Configuring for pm9263 - Board: pm9263, Options: AT91SAM9263 textdata bss dec hex filename 225515 11028 72264 308807 4b647 ./u-boot Applied to u-boot-atmel/master, thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][AT91 rework 1/1] make pm9g45 buildable for v2011.06 release
Dear Asen Chavdarov Dimov, Signed-off-by: Asen Chavdarov Dimov di...@ronetix.at --- Makefile |4 board/ronetix/pm9g45/pm9g45.c | 30 ++ boards.cfg|1 + include/configs/pm9g45.h | 16 +++- 4 files changed, 26 insertions(+), 25 deletions(-) Hand added removal from MAKEALL, changed: at91_serial_hw_init -- at91_seriald_hw_init Configuring for pm9g45 - Board: pm9g45, Options: AT91SAM9G45 textdata bss dec hex filename 2096275952 71792 287371 4628b ./u-boot Applied result to u-boot-atmel/master, thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT91: fix at91sam9g45.h to include USB Host defines
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de --- arch/arm/include/asm/arch-at91/at91sam9g45.h |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/include/asm/arch-at91/at91sam9g45.h b/arch/arm/include/asm/arch-at91/at91sam9g45.h index 4df6b09..1aeedc0 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9g45.h +++ b/arch/arm/include/asm/arch-at91/at91sam9g45.h @@ -144,7 +144,9 @@ * Other misc defines */ #define ATMEL_PIO_PORTS5 /* this SoCs has 5 PIO */ - +#define ATMEL_BASE_PIO ATMEL_BASE_PIOA +#define ATMEL_PMC_UHP AT91SAM926x_PMC_UHP +#define ATMEL_ID_UHP ATMEL_ID_UHPHS /* * Cpu Name */ -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] atmel: Update support of board AT91SAM9M10G45-EK to new style
Dear Thomas Petazzoni, Le Thu, 04 Aug 2011 20:21:58 +, Reinhard Meyer u-b...@emk-elektronik.de a écrit : AND this board's early_init_f is quite different from the other atmel boards, also the place of calling at91_seriald_hw_init() is different from them. If at91_seriald_hw_init() isn't called in early_init_f, then the U-Boot 2011.06- (Aug 04 2011 ...) message isn't displayed on the debug serial port. That would mean, that the other boards would not display the message either..!? I cannot verify this, I can only verify seamless build.. So please fix the two issues I mentioned: board removal from MAKEALL and missing return value of board_early_init_f(). Thank you, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] atmel: Update support of board AT91SAM9M10G45-EK to new style
Dear Thomas Petazzoni, Based on earlier work by Alex Waterman awater...@dawning.com. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- MAKEALL |1 - Makefile| 21 --- board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 115 -- board/atmel/at91sam9m10g45ek/led.c |6 +- boards.cfg |1 + include/configs/at91sam9m10g45ek.h | 193 ++- 6 files changed, 155 insertions(+), 182 deletions(-) Configuring for at91sam9m10g45ek_nandflash - Board: at91sam9m10g45ek, Options: AT91SAM9M10G45,SYS_USE_NANDFLASH textdata bss dec hex filename 201528 32116 71768 305412 4a904 ./u-boot Applied to u-boot-atmel/master, board removal patch set to Not Applicable, thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL REQUEST] u-boot-atmel/master
Dear Albert, more boards are fixed. I doubt I will get fixes for at91cap9adk. MAKEALL at91: - SUMMARY Boards compiled: 55 Boards with warnings or errors: 1 ( at91cap9adk ) -- Best Regards, Reinhard --- The following changes since commit 7a619ab30a0db64c22fb053702c41a94f05cf648: arm: auto gen asm-offsets.h for mb86r0x (2011-08-04 13:56:55 +0200) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master Asen Dimov (3): pm9261: compiles with the AT91 reworked scheme make pm9263 buildable for v2011.06 release make pm9g45 buildable for v2011.06 release Matthias Fuchs (1): at91: reworked support for meesc board Reinhard Meyer (1): AT91: fix at91sam9g45.h to include USB Host defines Thomas Petazzoni (4): sbc35_a9g20: update board to the new AT91 organization tny_a9260/tny_a9g20: update board to the new AT91 organization atmel: update at91sam9m10g45 SoC support to new style atmel: Update support of board AT91SAM9M10G45-EK to new style MAKEALL|8 +- Makefile | 46 - .../cpu/arm926ejs/at91/at91sam9m10g45_devices.c| 114 ++-- arch/arm/include/asm/arch-at91/at91sam9g45.h | 16 ++- .../arm/include/asm/arch-at91/at91sam9g45_matrix.h | 194 +++ board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c| 115 ++- board/atmel/at91sam9m10g45ek/led.c |6 +- board/calao/sbc35_a9g20/sbc35_a9g20.c | 88 + board/calao/tny_a9260/tny_a9260.c | 55 +++--- board/esd/meesc/config.mk |1 - board/esd/meesc/meesc.c| 49 +++--- board/ronetix/pm9261/led.c |9 +- board/ronetix/pm9261/pm9261.c | 38 ++-- board/ronetix/pm9263/led.c |9 +- board/ronetix/pm9263/pm9263.c | 42 ++-- board/ronetix/pm9g45/pm9g45.c | 32 ++-- boards.cfg | 12 +- include/configs/at91sam9m10g45ek.h | 193 +-- include/configs/meesc.h| 202 include/configs/pm9261.h | 18 +- include/configs/pm9263.h | 17 +- include/configs/pm9g45.h | 16 +- include/configs/sbc35_a9g20.h | 87 - include/configs/tny_a9260.h| 85 24 files changed, 694 insertions(+), 758 deletions(-) delete mode 100644 board/esd/meesc/config.mk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master -- updated
Dear Wolfgang, Hm... current build results are shattering; building for ARM with good old ELDK 4.2 gives this: - SUMMARY Boards compiled: 201 Boards with warnings or errors: 99 ( assabet dnp1110 gcplus lart shannon ap7 ap720t armadillo B2 ep7312 evb4510 impa7 integratorap lpc2292sodimm modnet50 SMN42 ap920t ap922_XA10 ap926ejs ap946es ap966 cp920t cp922_XA10 cp926ejs cp946es cp966 edb9301 edb9302 edb9302a edb9307 edb9307a edb9312 edb9315 edb9315a imx27lite jadecpu lpd7a400 magnesium mx1fs2 netstar sbc2410x scb9328 smdk2400 smdk2410 spear300 spear310 spear320 spear600 VCMA9 versatile versatileab versatilepb voiceblue integratorcp cp1026 cp1136 omap2420h4 apollon imx31 litekit imx31_phycore imx31_phycore_eet mx31ads mx31pdk mx31pdk_nand qong dig297 igep0020 mx51evk omap3_beagle omap3_overo omap3_evm omap3_zoom2 omap4_panda omap4_sdp4430 -- at91cap9adk meesc meesc_dataflash pm9261 pm9263 at91sam9m10g45ek pm9g45 SBC35_A9G20 TNY_A9260 TNY_A9G20 -- csb226 lubbock zylonite actux1_4_16 actux1_8_16 actux1_4_32 actux1_8_32 actux2 actux3 actux4 dvlhost ixdp425 ixdpg425 pdnb3 scpu ) -- For the Atmel boards this is correct for the current state of the ARM repo. It concurs with what my 4.5.2 gnu toolchain (running on 32 BIT) says. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master -- updated
Dear Wolfgang, Hm... current build results are shattering; building for ARM with good old ELDK 4.2 gives this: - SUMMARY Boards compiled: 201 Boards with warnings or errors: 99 ( assabet dnp1110 gcplus lart shannon ap7 ap720t armadillo B2 ep7312 evb4510 impa7 integratorap lpc2292sodimm modnet50 SMN42 ap920t ap922_XA10 ap926ejs ap946es ap966 cp920t cp922_XA10 cp926ejs cp946es cp966 edb9301 edb9302 edb9302a edb9307 edb9307a edb9312 edb9315 edb9315a imx27lite jadecpu lpd7a400 magnesium mx1fs2 netstar sbc2410x scb9328 smdk2400 smdk2410 spear300 spear310 spear320 spear600 VCMA9 versatile versatileab versatilepb voiceblue integratorcp cp1026 cp1136 omap2420h4 apollon imx31 litekit imx31_phycore imx31_phycore_eet mx31ads mx31pdk mx31pdk_nand qong dig297 igep0020 mx51evk omap3_beagle omap3_overo omap3_evm omap3_zoom2 omap4_panda omap4_sdp4430 -- at91cap9adk meesc meesc_dataflash pm9261 pm9263 at91sam9m10g45ek pm9g45 SBC35_A9G20 TNY_A9260 TNY_A9G20 -- csb226 lubbock zylonite actux1_4_16 actux1_8_16 actux1_4_32 actux1_8_32 actux2 actux3 actux4 dvlhost ixdp425 ixdpg425 pdnb3 scpu ) -- For the Atmel boards this is correct for the current state of the ARM repo. It concurs with what my 4.5.2 gnu toolchain (running on 32 BIT) says. That even concurs with what Albert has written after merging the Atmel repo: Overall ARM builds (./MAKEALL arm) went from 199 boards built, 119 with warnings or errors before applying, to 201 boards, 97 with warnings or errors once applied. So it is about the same for EDLK (on 64 Bit?) I just pulled u-boot.git/master. It builds fine for all AT91 boards that have been fixed in that repo. Question is: what goes wrong if ELDK is on 32 Bit? Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Dear Hong Xu,
After DMA operation, we need to maintain D-Cache coherency.
We need to clean cache (write back the dirty lines) and then
make the cache invalidate as well(hence CPU will fetch data
written by DMA controller from RAM).
Tested on AT91SAM9261EK with Peripheral DMA controller.
Signed-off-by: Hong Xuhong...@atmel.com
Tested-by: Elen Songelen.s...@atmel.com
CC: Albert Aribaudalbert.arib...@free.fr
CC: Heiko Schocherh...@denx.de
---
Changes since v1
~ Per Albert's suggestion, add invalidate_dcache_range originally defined
in include/common.h
arch/arm/lib/cache.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c
index 92b61a2..0436443 100644
--- a/arch/arm/lib/cache.c
+++ b/arch/arm/lib/cache.c
@@ -53,3 +53,49 @@ void __flush_dcache_all(void)
}
voidflush_dcache_all(void)
__attribute__((weak, alias(__flush_dcache_all)));
+
+void __invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+ int cache_line_len;
+ unsigned long mva;
+
+#ifdef CONFIG_ARM926EJS
+
+#ifdef CONFIG_SYS_CACHELINE_SIZE
+ cache_line_len = CONFIG_SYS_CACHELINE_SIZE;
+#else
+ cache_line_len = 32;
+#endif
+ /*
+ * If start and stop are not aligned to cache-line,
+ * the adjacent lines will be cleaned
+ */
+ if ((start (cache_line_len - 1)) != 0)
+ asm(mcr p15, 0, %0, c7, c10, 1 : : r (start));
+ if ((stop (cache_line_len - 1)) != 0)
+ asm(mcr p15, 0, %0, c7, c10, 1 : : r (stop));
Why so complicated?
How about:
/* round down to the start of the cache line */
start = (cache_line_len - 1);
/* round up to the end of the cache line */
note: if, what I assume, the range to be invalidated is
[start, stop) - that means stop is the first address not to be
invalidated, the next statement is not necessary
stop |= (cache_line_len - 1);
while (start stop) {
asm(mcr p15, 0, %0, c7, c6, 1 : : r(start));
start += cache_line_len;
}
/* Drain the WB */
asm(mcr p15, 0, %0, c7, c10, 4 : : r (0));
+#endif
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL REQUEST] u-boot-atmel/master
Dear Albert, Overall ARM builds (./MAKEALL arm) went from 199 boards built, 119 with warnings or errors before applying, to 201 boards, 97 with warnings or errors once applied. When boards were defined in the MAKEALL apparently only one variant was built and counted, whereas in boards.cfg every variant is built. Amongst that 199 some Atmel boards had been in MAKEALL *and* boards.cfg Removing those duplicates but getting more variants tested leads to that increase of 2. On a side note one should make sure that boards are not left in MAKEALL when they are moved from Makefile to boards.cfg. Otherwise one gets them counted as broken although there is no error or warning message seen. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Add missing boards to MAKEALL
Dear Albert, After Reinhard's remark on boards.cfg vs MAKEALL, I may have accepted the patch a bit hastily. All of these boards are already in boards.cfg, and need not be in makeall IIUC. Thus, I am rolling back master one notch and will mark the patch as Supersedes (could not find a better match for not needed any more) ... or not: here, adding this patch should have resulted in 12 more boards built and 12 more boards failing to build, but actuelly 9 succeed. Reinhard, are you sure that boards that are in boards.cfg *and* in MAKEALL will fail to build? This is not consistent with what I see here with this patch. When at91sam9261 was still in MAKEALL, it did build clean (no errors or warnings), but the report at the end of a MAKEALL run had it in the list of boards with problems. After removing it from MAKEALL the effect was gone. I also noticed that it was not build twice, as one might expect. Maybe the effect was only there with an explicit MAKEALL at91, I don't know - and its not worth to experiment there :) On any account, however, boards in boards.cfg are automatically included in a MAKEALL run. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AT91:mmc:fix multiple read/write error
Dear Andy, dear Elen,
According to datasheet,set block count before multiple read/write.
Signed-off-by: elen.song elen.s...@atmel.com
---
drivers/mmc/atmel_mci.h |9 -
drivers/mmc/gen_atmel_mci.c |4
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/atmel_mci.h b/drivers/mmc/atmel_mci.h
index 90ab6a8..3095d22 100644
--- a/drivers/mmc/atmel_mci.h
+++ b/drivers/mmc/atmel_mci.h
@@ -36,7 +36,7 @@ typedef struct atmel_mci {
u32 sdcr; /* 0x0c */
u32 argr; /* 0x10 */
u32 cmdr; /* 0x14 */
- u32 _18;/* 0x18 */
+ u32 blkr; /* 0x18 */
u32 _1c;/* 0x1c */
u32 rspr; /* 0x20 */
u32 rspr1; /* 0x24 */
@@ -67,6 +67,7 @@ typedef struct atmel_mci {
#define MMCI_SDCR0x000c
#define MMCI_ARGR0x0010
#define MMCI_CMDR0x0014
+#define MMCI_BLKR0x0018
#define MMCI_RSPR0x0020
#define MMCI_RSPR1 0x0024
#define MMCI_RSPR2 0x0028
@@ -140,6 +141,12 @@ typedef struct atmel_mci {
#define MMCI_TRTYP_OFFSET19
#define MMCI_TRTYP_SIZE 2
+/* Bitfields in BLKR */
+#define MMCI_BCNT_OFFSET 0
+#define MMCI_BCNT_SIZE 16
+#define MMCI_BLKLEN_OFFSET 16
+#define MMCI_BLKLEN_SIZE 16
+
/* Bitfields in RSPRx */
#define MMCI_RSP_OFFSET 0
#define MMCI_RSP_SIZE32
diff --git a/drivers/mmc/gen_atmel_mci.c b/drivers/mmc/gen_atmel_mci.c
index f346b24..d217574 100644
--- a/drivers/mmc/gen_atmel_mci.c
+++ b/drivers/mmc/gen_atmel_mci.c
@@ -183,6 +183,10 @@ mci_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
/* Figure out the transfer arguments */
cmdr = mci_encode_cmd(cmd, data, error_flags);
+ if (data)
+ writel(MMCI_BF(BCNT, data-blocks) |
+ MMCI_BF(BLKLEN, mmc-read_bl_len), mci-blkr);
+
/* Send the command */
writel(cmd-cmdarg, mci-argr);
writel(cmdr, mci-cmdr);
I find it highly irregular that this patch has made it into mainline!
1. We have had a discussion about that I think the approach in this
patch is wrong. My concerns have not been addressed yet.
2. This is clearly an ATMEL domain/custodian patch.
3. I was not put on CC by Elen.
4. Andy snapped it away and applied it without sending an Applied to
message.
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] macb: fix compile warning
Dear Wolfgang Denk, Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message1307619188-18655-1-git-send-email-andreas.de...@gmail.com you wrote: This patch fixes following compile warning: ---8--- macb.c: In function 'macb_write_hwaddr': macb.c:525:2: warning: dereferencing type-punned pointer will break strict-aliasing rules ---8--- Signed-off-by: Andreas Bießmannandreas.de...@gmail.com This doesn't apply. Can you please rebase and resubmit? Thanks. V2 of this patch has been mainlined in June already. Note: macb is the LAN driver for all Atmel ARM and AVR32 SoCs. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH, AT91, rework v2] change common at91sam9261 files after AT91 rework
Dear Asen Dimov,
Signed-off-by: Asen Dimov di...@ronetix.at
---
Note:
This patch was a part of patches, but it is better to be done step by step and
so this patch is a split from the patch series with message id:
1307606409-29818-2-git-send-email-di...@ronetix.at
and Patchwork:
http://patchwork.ozlabs.org/patch/99665/
Changes for v2:
- add CONFIG_AT91_GPIO_PIULLUP
- reneme at91_serial3_hw_init() to at91_seriald_hw_init()
- remove at91_serial_hw_init()
What I miss in at91sam9261_devices.c (as compared to the 9260)
is support for MACB and MCI. Don't 9261 systems use Ethernet?
Or is that part still in the board specific files?
Then, I would like to add the following changes:
-- arch/arm/cpu/arm926ejs/at91/at91sam9261_devices.c
@@ -79,14 +79,14 @@ void at91_seriald_hw_init(void)
writel(1 ATMEL_ID_SYS, pmc-pcer);
}
-#ifdef CONFIG_HAS_DATAFLASH
+#if defined(CONFIG_HAS_DATAFLASH) || defined(CONFIG_ATMEL_SPI)
void at91_spi0_hw_init(unsigned long cs_mask)
{
at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
- at91_set_a_periph(AT91_PIO_PORTA, 0, 0);/* SPI0_MISO */
- at91_set_a_periph(AT91_PIO_PORTA, 1, 0);/* SPI0_MOSI */
- at91_set_a_periph(AT91_PIO_PORTA, 2, 0);/* SPI0_SPCK */
+ at91_set_a_periph(AT91_PIO_PORTA, 0, PUP); /* SPI0_MISO */
+ at91_set_a_periph(AT91_PIO_PORTA, 1, PUP); /* SPI0_MOSI */
+ at91_set_a_periph(AT91_PIO_PORTA, 2, PUP); /* SPI0_SPCK */
/* Enable clock */
writel(1 ATMEL_ID_SPI0, pmc-pcer);
@@ -121,9 +121,9 @@ void at91_spi1_hw_init(unsigned long cs_mask)
{
at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
- at91_set_a_periph(AT91_PIO_PORTB, 30, 0); /* SPI1_MISO */
- at91_set_a_periph(AT91_PIO_PORTB, 31, 0); /* SPI1_MOSI */
- at91_set_a_periph(AT91_PIO_PORTB, 29, 0); /* SPI1_SPCK */
+ at91_set_a_periph(AT91_PIO_PORTB, 30, PUP); /* SPI1_MISO */
+ at91_set_a_periph(AT91_PIO_PORTB, 31, PUP); /* SPI1_MOSI */
+ at91_set_a_periph(AT91_PIO_PORTB, 29, PUP); /* SPI1_SPCK */
/* Enable clock */
writel(1 ATMEL_ID_SPI1, pmc-pcer);
- arch/arm/include/asm/arch-at91/at91sam9261.h
@@ -104,7 +104,7 @@
#define ATMEL_SIZE_SRAM0x00028000 /* Internal SRAM size
(160Kb) */
#define ATMEL_BASE_ROM 0x0040 /* Internal ROM base address */
-#define ATMEL_SIZE_ROM SZ_32K /* Internal ROM size (32Kb) */
+#define ATMEL_SIZE_ROM 0x8000 /* Internal ROM size (32Kb) */
#define ATMEL_BASE_UHP 0x0050 /* USB Host controller */
#define ATMEL_BASE_LCDC0x0060 /* LDC controller */
I have this as a local patch and could squash this onto yours, or
you may provide an updated patch.
Thanks,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT91: fix mistake in at91sam9260_devices.c(spi1_hw_init)
Bits 0..3 in cs_mask = CS0..CS3 in SPI mode require it to be peripheral
Bits 4..7 in cs_mask = CS0..CS3 in GPIO mode require it to be output
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
b/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
index 6bdc75c..65b8d51 100644
--- a/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
+++ b/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
@@ -138,7 +138,7 @@ void at91_spi1_hw_init(unsigned long cs_mask)
at91_set_b_periph(AT91_PIO_PORTC, 4, 1);
}
if (cs_mask (1 3)) {
- at91_set_pio_output(AT91_PIO_PORTC, 3, 1);
+ at91_set_b_periph(AT91_PIO_PORTC, 3, 1);
}
if (cs_mask (1 4)) {
at91_set_pio_output(AT91_PIO_PORTB, 3, 1);
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] AT91: EMK/TOP9000 board actualization
This is a general update of all projects involving the TOP9000 CPU module.
Changes:
Enable the /RESET input
Add more ARCH numbers
Add EAN13 checksum routine
Add reading of VPD EEPROM
Remove obsolete reset_phy()
Add boot progress LEDs
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
board/emk/top9000/top9000.c | 131 ++-
1 files changed, 116 insertions(+), 15 deletions(-)
diff --git a/board/emk/top9000/top9000.c b/board/emk/top9000/top9000.c
index 61dee62..92e8a9d 100644
--- a/board/emk/top9000/top9000.c
+++ b/board/emk/top9000/top9000.c
@@ -126,6 +126,7 @@ int board_mmc_getcd(u8 *cd, struct mmc *mmc)
int board_early_init_f(void)
{
struct at91_shdwn *shdwn = (struct at91_shdwn *)ATMEL_BASE_SHDWN;
+ struct at91_rstc *rstc = (struct at91_rstc *)ATMEL_BASE_RSTC;
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
/*
@@ -135,6 +136,13 @@ int board_early_init_f(void)
writel(AT91_SHDW_MR_WKMODE0H2L | AT91_SHDW_MR_WKMODE0L2H,
shdwn-mr);
+ /*
+* make sure the board can be reset by
+* low level on nRST
+*/
+ writel(AT91_RSTC_KEY | AT91_RSTC_MR_URSTEN,
+ rstc-mr);
+
/* Enable clocks for all PIOs */
writel((1 ATMEL_ID_PIOA) | (1 ATMEL_ID_PIOB) |
(1 ATMEL_ID_PIOC),
@@ -160,8 +168,14 @@ int board_early_init_f(void)
int board_init(void)
{
- /* arch number of TOP9000 Board */
- gd-bd-bi_arch_number = MACH_TYPE_TOP9000;
+ /* arch numbers of TOP9000 and baseboards */
+#if defined(CONFIG_EVAL9000)
+ gd-bd-bi_arch_number = MACH_TYPE_TOP9000_EVAL;
+#elif defined(CONFIG_SU9000)
+ gd-bd-bi_arch_number = MACH_TYPE_TOP9000_SU;
+#else
+ gd-bd-bi_arch_number = MACH_TYPE_TOP9000;
+#endif
/* adress of boot parameters */
gd-bd-bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
@@ -183,10 +197,97 @@ int board_init(void)
}
#ifdef CONFIG_MISC_INIT_R
+static int checksum(char *p)
+{
+ int sum = 0;
+ int i = 13;
+
+ while (i 0) {
+ if (*p '0' || *p '9')
+ return -1;
+ sum += *p;
+ if (!(i 1))
+ sum += 2 * *p;
+ --i;
+ ++p;
+ }
+ return sum % 10;
+}
+
int misc_init_r(void)
{
/* read 'factory' part of EEPROM */
- read_factory_r();
+ char buf[32];
+ char tag[4];
+ uint addr = CONFIG_SYS_FACT_OFFSET;
+ uint len = CONFIG_SYS_FACT_SIZE;
+ int have_top = 0;
+
+ /* read entries */
+ while (len = 16) {
+ /* read one entry */
+ if (eeprom_read(CONFIG_SYS_I2C_FACT_ADDR,
+ addr, (uchar *)buf, 16))
+ goto bailout;
+ addr += 16;
+ len -= 16;
+ /* get tag field */
+ tag[0] = buf[0];
+ tag[1] = buf[1];
+ tag[2] = buf[2];
+ tag[3] = 0;
+ /* skip entries with bad checksum */
+ if (checksum(buf + 3))
+ continue;
+ /* test for specific entries */
+ if (!strcmp(tag, TOP)) {
+ unsigned serialno;
+ /* retrieve serialnumber */
+ buf[15] = 0;
+ serialno = simple_strtoul(buf + 10, NULL, 10);
+ buf[10] = 0;
+ setenv(board_id, buf);
+ sprintf(buf, %05d, serialno);
+ setenv(serial#, buf);
+ sprintf(buf, 00:80:d9:0d:%02x:%02x,
+ serialno / 256,
+ serialno % 256);
+ setenv(ethaddr, buf);
+ have_top = 1;
+ } else if (!strcmp(tag, MA2)) {
+ unsigned serialno;
+ /* retrieve serialnumber */
+ buf[15] = 0;
+ serialno = simple_strtoul(buf + 10, NULL, 10);
+ sprintf(buf, 00:80:d9:0e:%02x:%02x,
+ serialno / 256,
+ serialno % 256);
+ setenv(eth2addr, buf);
+ } else if (!strcmp(tag, MA3)) {
+ unsigned serialno;
+ /* retrieve serialnumber */
+ buf[15] = 0;
+ serialno = simple_strtoul(buf + 10, NULL, 10);
+ sprintf(buf, 00:80:d9:0e:%02x:%02x,
+ serialno / 256,
+ serialno % 256);
+ setenv(eth3addr, buf);
+ } else if (!strcmp(tag, MA4)) {
+ unsigned serialno;
+ /* retrieve serialnumber
Re: [U-Boot] [PATCH, AT91, rework v2] change common at91sam9261 files after AT91 rework
Dear Asen Dimov, and one forgotten answer ... What I miss in at91sam9261_devices.c (as compared to the 9260) is support for MACB and MCI. Don't 9261 systems use Ethernet? Or is that part still in the board specific files? that part is in the board file. Sorry for that confusion. I just checked the 9261 data sheet and to my surprise the 9261 does not have a MACB or any other LAN interface on the SoC! It seems that the 9261-ek and derivatives use an external LAN chip, DM9000. That chip's initialisation, of course, does not belong into the 9261 SoC code. So it must stay in the board code. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH, AT91, rework v2] change common at91sam9261 files after AT91 rework
Dear Asen Dimov, and one forgotten answer ... What I miss in at91sam9261_devices.c (as compared to the 9260) is support for MACB and MCI. Don't 9261 systems use Ethernet? Or is that part still in the board specific files? that part is in the board file. That is unfortunate. I'd like to move that into the SoC specific file. Otherwise that code would be duplicated in each board. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AT91: fix mistake in at91sam9260_devices.c(spi1_hw_init)
Dear Reinhard Meyer, Bits 0..3 in cs_mask = CS0..CS3 in SPI mode require it to be peripheral Bits 4..7 in cs_mask = CS0..CS3 in GPIO mode require it to be output Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de --- arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied to u-boot-atmel/master. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH, AT91, rework v2] change common at91sam9261 files after AT91 rework
Dear Asen Dimov, I have this as a local patch and could squash this onto yours, or you may provide an updated patch. I will try once more to make it as it should be. The squashed version is at top of u-boot-atmel/rework-at91sam9261. If you are OK with that, I'll post the patch and apply it to master. (I also changed the subject a bit) Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT91: change common at91sam9261 files to compile with new scheme
From: Asen Dimov di...@ronetix.at
Signed-off-by: Asen Dimov di...@ronetix.at
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/cpu/arm926ejs/at91/at91sam9261_devices.c | 76 ++---
arch/arm/include/asm/arch-at91/at91sam9261.h |3 +-
2 files changed, 38 insertions(+), 41 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9261_devices.c
b/arch/arm/cpu/arm926ejs/at91/at91sam9261_devices.c
index b4353ef..edc7972 100644
--- a/arch/arm/cpu/arm926ejs/at91/at91sam9261_devices.c
+++ b/arch/arm/cpu/arm926ejs/at91/at91sam9261_devices.c
@@ -23,77 +23,73 @@
*/
#include common.h
+#include asm/io.h
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
#include asm/arch/gpio.h
-#include asm/arch/io.h
+
+/*
+ * if CONFIG_AT91_GPIO_PULLUP ist set, keep pullups on on all
+ * peripheral pins. Good to have if hardware is soldered optionally
+ * or in case of SPI no slave is selected. Avoid lines to float
+ * needlessly. Use a short local PUP define.
+ *
+ * Due to errata TXD floats when CTS is inactive pullups are always
+ * on for TXD pins.
+ */
+#ifdef CONFIG_AT91_GPIO_PULLUP
+# define PUP CONFIG_AT91_GPIO_PULLUP
+#else
+# define PUP 0
+#endif
void at91_serial0_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTC, 8, 1);/* TXD0 */
at91_set_a_periph(AT91_PIO_PORTC, 9, 0);/* RXD0 */
- writel(1 AT91SAM9261_ID_US0, pmc-pcer);
+ writel(1 ATMEL_ID_USART0, pmc-pcer);
}
void at91_serial1_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTC, 12, 1); /* TXD1 */
at91_set_a_periph(AT91_PIO_PORTC, 13, 0); /* RXD1 */
- writel(1 AT91SAM9261_ID_US1, pmc-pcer);
+ writel(1 ATMEL_ID_USART1, pmc-pcer);
}
void at91_serial2_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTC, 14, 1); /* TXD2 */
at91_set_a_periph(AT91_PIO_PORTC, 15, 0); /* RXD2 */
- writel(1 AT91SAM9261_ID_US2, pmc-pcer);
+ writel(1 ATMEL_ID_USART2, pmc-pcer);
}
-void at91_serial3_hw_init(void)
+void at91_seriald_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTA, 9, 0);/* DRXD */
at91_set_a_periph(AT91_PIO_PORTA, 10, 1); /* DTXD */
- writel(1 AT91_ID_SYS, pmc-pcer);
-}
-
-void at91_serial_hw_init(void)
-{
-#ifdef CONFIG_USART0
- at91_serial0_hw_init();
-#endif
-
-#ifdef CONFIG_USART1
- at91_serial1_hw_init();
-#endif
-
-#ifdef CONFIG_USART2
- at91_serial2_hw_init();
-#endif
-
-#ifdef CONFIG_USART3 /* DBGU */
- at91_serial3_hw_init();
-#endif
+ writel(1 ATMEL_ID_SYS, pmc-pcer);
}
-#ifdef CONFIG_HAS_DATAFLASH
+#if defined(CONFIG_HAS_DATAFLASH) || defined(CONFIG_ATMEL_SPI)
void at91_spi0_hw_init(unsigned long cs_mask)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
- at91_set_a_periph(AT91_PIO_PORTA, 0, 0);/* SPI0_MISO */
- at91_set_a_periph(AT91_PIO_PORTA, 1, 0);/* SPI0_MOSI */
- at91_set_a_periph(AT91_PIO_PORTA, 2, 0);/* SPI0_SPCK */
+ at91_set_a_periph(AT91_PIO_PORTA, 0, PUP); /* SPI0_MISO */
+ at91_set_a_periph(AT91_PIO_PORTA, 1, PUP); /* SPI0_MOSI */
+ at91_set_a_periph(AT91_PIO_PORTA, 2, PUP); /* SPI0_SPCK */
/* Enable clock */
- writel(1 AT91SAM9261_ID_SPI0, pmc-pcer);
+ writel(1 ATMEL_ID_SPI0, pmc-pcer);
if (cs_mask (1 0)) {
at91_set_a_periph(AT91_PIO_PORTA, 3, 1);
@@ -123,14 +119,14 @@ void at91_spi0_hw_init(unsigned long cs_mask)
void at91_spi1_hw_init(unsigned long cs_mask)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
- at91_set_a_periph(AT91_PIO_PORTB, 30, 0); /* SPI1_MISO */
- at91_set_a_periph(AT91_PIO_PORTB, 31, 0); /* SPI1_MOSI */
- at91_set_a_periph(AT91_PIO_PORTB, 29, 0); /* SPI1_SPCK */
+ at91_set_a_periph(AT91_PIO_PORTB, 30, PUP); /* SPI1_MISO */
+ at91_set_a_periph(AT91_PIO_PORTB, 31, PUP); /* SPI1_MOSI */
+ at91_set_a_periph(AT91_PIO_PORTB, 29, PUP); /* SPI1_SPCK */
/* Enable clock */
- writel(1 AT91SAM9261_ID_SPI1, pmc-pcer);
+ writel(1 ATMEL_ID_SPI1, pmc-pcer);
if (cs_mask (1 0
Re: [U-Boot] [PATCH] AT91: change common at91sam9261 files to compile with new scheme
Dear Asen Dimov, Reinhard Meyer: From: Asen Dimov di...@ronetix.at Signed-off-by: Asen Dimov di...@ronetix.at Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de --- arch/arm/cpu/arm926ejs/at91/at91sam9261_devices.c | 76 ++--- arch/arm/include/asm/arch-at91/at91sam9261.h |3 +- 2 files changed, 38 insertions(+), 41 deletions(-) Applied to u-boot-atmel/master. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2][ARM] eb_cpux9k2: add USB host support to board
Dear Jens Scharsig, Wolfgang Denk, Dear u-b...@emk-elektronik.de, In message 1310382637.7288.7.camel@ubuntu you wrote: The patch you sent as an attachment does indeed apply, but I remember its against the rules to use it; however patchworks does correctly Indeed patches shpuld be sent inline which makes reviewing and commenting much easier. handle it and I could get it with pwclient get 104091; so IMHO it should be fine to use it - Wolfgang? If it's OK with you, just go on and apply it. Applied to u-boot-atmel/next Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] AT91: EMK/TOP9000 board actualization
Dear Reinhard Meyer, This is a general update of all projects involving the TOP9000 CPU module. Changes: Enable the /RESET input Add more ARCH numbers Add EAN13 checksum routine Add reading of VPD EEPROM Remove obsolete reset_phy() Add boot progress LEDs Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de --- board/emk/top9000/top9000.c | 131 ++- 1 files changed, 116 insertions(+), 15 deletions(-) Removed trailing empty line. Applied to u-boot-atmel/next. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AT91: rework and fixes (was:Re: [PATCH 47/52] ARM: remove broken at91sam9261ek /at91sam9g10ek boards)
Dear Hong Xu, Hi Albert, On 07/18/2011 02:39 PM, Albert ARIBAUD wrote: Hi Eric, Le 18/07/2011 04:52, Hong Xu a écrit : Hi Reinhard, It's a pity to see that some of the AT91 boards are planed to be removed by Wolfgang. Several weeks ago, the patches for SAM9261/9G10 have got Acks from you. See http://www.mail-archive.com/u-boot@lists.denx.de/msg54829.html But I don't know why it's not merged upstream. Now, an actual at91sam9261_devices.c and at91sam9261.h are on top of u-boot-atmel/master. If your board patches for az91sam9261-ek still work with that, I can apply them again to master. For SAM9RL, the V3 patches have been sent long time ago and was pinged. But no response any longer. I have changes requested there. The similar stories are also applied for SAM9263 and SAM9M10G45. Changes requested as well. We of course need the mainline support for all SAM9 boards in U-Boot. But it's the time we need your plans/suggestions/NAKs/ACKs to move on. Thanks. Note: I'll naturally defer the decision of what to make with the AT91 boards to Reinhard, and likewise to other ARM custodians for boards the architecture of which falls under their 'jurisdiction'. Understand. But it looks like Reinhard has bunch of paid work at hand and he has his vocation in the near future (He mentioned this in an email towards Wolfgang's [U-Boot] [PATCH 00/52] ARM: remove broken boards). We noticed that there are several AT91 fixes in the mailing list without any response. This is not true. Most have been commented and changes requested. As a suggestion, how about we setup a git branch and collect AT91 related patches during Reinhard's busy time and vocation time? If yes, can we ask for `pull request' from you? I do not think such a diagonal approach is desired by anyone. Anyway, for work reasons, there will be no extended vacation this summer :( Again, the work flow, as I want it followed, is as such: 1. convert/fix all SoC specific files for 9263 9g45 etc. to be in line and equivalent to the now existing files for 9260 and 9261. (Next should be for 9263, we should be looking at existing patches to fix that SoC). I will NOT accept patches that do not fully implement the name schemes laid out in 9260 and 9261. 2. Fix any boards to use those files AND to use relocation properly. 3. Make sure those build without warning or errors. 4. Make sure those boards still boot with that u-boot. 5. When a board has passed those tests (I cannot test point 4) the removal patch for that board will not be applied. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Drop obsolete at91rm9200 support
On 23.07.2011 15:41, Albert ARIBAUD wrote: Hi Reinhard, Le 21/07/2011 14:05, Reinhard Meyer a écrit : Dear Wolfgang Denk, The series ARM: remove broken boards deletes the last few boards which used the obsolete arm920t/at91rm9200 arch code. This series completes it and removes the now obsolete at91rm9200 arch code completely. Additionally ther are some more cleanup in documentation and surrounding code. ... I think it would be good to apply those patches removing the old, superseded at91rm9200 files to master instead of next. Would that be ok? Yes, I appreciate this. Series applied to u-boot-atmel/master. Thanks, Reinhard Do you mean you've applied Wolfgang's 50-odd patchset removing boards and then Andreas' patch? Of course not! Only the Series 1/6 to 6/6 of that Drop obsolete at91rm9200 That's not a broken board removal anyway. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] avr32: add grasshopper (ICnova AP7000) board
Dear Andreas Bießmann: Am 01.07.2011 16:47, schrieb Andreas Bießmann: The grasshopper board is a neat avr32 evaluation kit produced by In-Circuit GmbH. See http://www.ic-board.de/product_info.php?info=p75_ICnova-AP7000-Base.html for detailed information about this device. Signed-off-by: Andreas Bießmann biessm...@corscience.de --- changes since v1: - use vim: set noet ts=8 for 80 char per line checking - replace blank indention by tab indention - add board_early_init_r to explicitely set the phy address to 0x00 changes since v2: - add MAINTAINERS entry chganges since v3: - remove previous commit 'MAINTAINERS: convert to utf-8' - encoding of this patch is defective since '�' in MAINTAINERS is ISO-8859-1 coded and everywhere else it is UTF-8 coded. MAINTAINERS|1 + board/in-circuit/grasshopper/Makefile | 45 +++ board/in-circuit/grasshopper/grasshopper.c | 112 boards.cfg |1 + include/configs/grasshopper.h | 198 5 files changed, 357 insertions(+), 0 deletions(-) create mode 100644 board/in-circuit/grasshopper/Makefile create mode 100644 board/in-circuit/grasshopper/grasshopper.c create mode 100644 include/configs/grasshopper.h Any objections to this patch? v4 was out before the merge window closed. I know you are right before your holiday ... but it would be great if you take this too. No objections. Applied to u-boot-atmel/master. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Drop obsolete at91rm9200 support
Dear Wolfgang Denk, The series ARM: remove broken boards deletes the last few boards which used the obsolete arm920t/at91rm9200 arch code. This series completes it and removes the now obsolete at91rm9200 arch code completely. Additionally ther are some more cleanup in documentation and surrounding code. ... I think it would be good to apply those patches removing the old, superseded at91rm9200 files to master instead of next. Would that be ok? Yes, I appreciate this. Series applied to u-boot-atmel/master. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] a/a/c/arm920t/at91/reset.c: drop obsolete CONFIG_AT91RM9200_USART
Dear Andreas Bießmann, The CONFIG_AT91RM9200_USART is an remnant of 18ed5e9550810e2fc5bf2c757aee47774609651c which deleted the at91rm9200_usart driver. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- arch/arm/cpu/arm920t/at91/reset.c |4 1 files changed, 0 insertions(+), 4 deletions(-) Applied to u-boot-atmel/master. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Drop obsolete at91rm9200 support
Dear Wolfgang, On 18.07.2011 21:41, Andreas Bießmann wrote: The series ARM: remove broken boards deletes the last few boards which used the obsolete arm920t/at91rm9200 arch code. This series completes it and removes the now obsolete at91rm9200 arch code completely. Additionally ther are some more cleanup in documentation and surrounding code. This series applies on top of the ARM: remove broken boards. Andreas Bießmann (6): ARM: remove obsolete at91rm9200 MAKEALL: remove obsolete at91rm9200 soc a/a/c/arm920t/cpu.c: remove CONFIG_AT91_LEGACY warning README.at91-soc: remove AT91(RM9200) joining notice net/eth.c: drop obsolete at91rm9200 support README: fix arm920t/at91 path MAKEALL |1 - README|2 +- arch/arm/cpu/arm920t/at91rm9200/Makefile | 56 -- arch/arm/cpu/arm920t/at91rm9200/bcm5221.c | 232 -- arch/arm/cpu/arm920t/at91rm9200/dm9161.c | 225 -- arch/arm/cpu/arm920t/at91rm9200/ether.c | 316 arch/arm/cpu/arm920t/at91rm9200/i2c.c | 192 - arch/arm/cpu/arm920t/at91rm9200/ks8721.c | 249 --- arch/arm/cpu/arm920t/at91rm9200/lowlevel_init.S | 169 - arch/arm/cpu/arm920t/at91rm9200/lxt972.c | 192 - arch/arm/cpu/arm920t/at91rm9200/reset.c | 71 -- arch/arm/cpu/arm920t/at91rm9200/spi.c | 151 arch/arm/cpu/arm920t/at91rm9200/timer.c | 160 arch/arm/cpu/arm920t/at91rm9200/usb.c | 53 -- arch/arm/cpu/arm920t/cpu.c|4 - arch/arm/include/asm/arch-at91rm9200/AT91RM9200.h | 812 - arch/arm/include/asm/arch-at91rm9200/hardware.h | 75 -- doc/README.at91-soc | 22 - net/eth.c |4 - 19 files changed, 1 insertions(+), 2985 deletions(-) delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/Makefile delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/bcm5221.c delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/dm9161.c delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/ether.c delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/i2c.c delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/ks8721.c delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/lowlevel_init.S delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/lxt972.c delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/reset.c delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/spi.c delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/timer.c delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/usb.c delete mode 100644 arch/arm/include/asm/arch-at91rm9200/AT91RM9200.h delete mode 100644 arch/arm/include/asm/arch-at91rm9200/hardware.h I think it would be good to apply those patches removing the old, superseded at91rm9200 files to master instead of next. Would that be ok? Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/52] ARM: remove broken boards
Dear Wolfgang Denk, Reinhard: There are a number of additional AT91 based boards that are currently broken. Some bail out in drivers/mtd/cfi_flash.c dure to undefined references to `reset_timer' (cpu9260, cpu9G20, ...), some due to asm/arch/io.h: No such file or directory errors (pm9261, ...), some because of error: 'AT91_PMC_BASE' undeclared etc. (pm9261, pm9263), etc. etc. As these errors look a bit different to me I did not include these board into the removal yet. Please comment if there is hope to see these fixes in the next 2...3 days, otherwise I can submit removal patches for them as well. Thanks. I am extremely occupied with work right now, also there is a planned holiday ahead, so right now I cannot continue with the rework effort for 9261 etc. fast enough to meet given deadlines. An option is, of course, that someone else might volunteer as Atmel custodian... Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2][ARM] eb_cpux9k2: add USB host support to board
Dear Jens Scharsig, This is a resend without modifications by mail client Really? It seems the patch was completely omitted.. :) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Dear J. William Campbell, All I have two comments regarding this discussion so far. First, I think using the time function name at all is a VERY BAD idea. People will confuse it with the normal c library function that returns the time of day since the epoch. One may say that they should RTFM, but it is lots easier to just use another name and avoid all such confusion. Second, I think forcing all systems to use 64 bit time stamps is not a good idea. The main purpose of the timer API is to provide hardware timeouts. 64 bits is vast overkill for such a purpose. Mandating 64 bit capability for all u-boots is I think counter-productive. A 32 bit timestamp in millisecond resolution plus udelay covers all practical cases. The 1 ms resolution is probably inadequate for performance measurement, but for every u-boot system that is sometimes used for performance measurement, there are 100 (probably even more, like 1000, but I don't really have the figures) systems that are just used to boot Linux or another stand alone program. So we may need a different API for performance measurement that uses higher resolution. On most larger CPUs, there are hardware timers that can already do this with minimal work. On some less-capable CPUs, it may be lots harder, but if you aren't doing performance measurement, you don't need it. So I suggest that mandating a 64 bit API for some of the processors (68K comes to mind) is not really a good idea. It seems counter to the elegant simplicity of the rest of u-boot to stick a 64 bit requirement on timestamps used to determine if the boot delay is expired. I can only FULLY agree here !!! Lets just keep the current functions udelay(us) and u32 get_timer(), the latter maybe without parameter. Remove all *masked() and *reset() functions and lets change the timeout values used in code that also NIOS uses to be 20ms more than the hardware requires. It does not really matter if a *timeout* of 20ms is blown up to 40ms. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Question]AT91: MMC read and multiple read failed
Hello Song, Elen,
Hello Reinhard:
I've tried your patch([PATCH] AT91: enable MMC on at91sam(9260/9g20/0xe)ek)
on uboot-atmel branch on at91sam9260.The sdcard is correctly initialized,but
when I test mmc read command, I found two issues.
1.while run command mmc read 2200 0 1 to read the first block,it will
cause gen_atmel_mci: CMDR 00051051 (17) ARGR (SR: 0c400025) Data
Transfer Failed.
Both read and write will fail.Sd1.0 and 2.0 cards face the same problem.
2.cmd 18(multiple read) failed,that means can not run mmc read 2200 0 2.
Do you have faced the same problem?
All worked fine when I tested the patch late last year.
Since then some changes to common MMC code have been done, perhaps
those affect the Atmel implementation?
To issues1: Data Transfer Failed is caused by transfer data lost(not
read),if MCCK too high the host may not receive the data.so I try to reduce
the MCCK frequency,it works.
No idea, the clock should be computed and set correctly in the code as is.
Have you investigated why it might be set too high for the card in question?
You are testing on a standard at91sam9260-ek? I can only test on a 9xe-ek,
but that should be the same.
To issues2: While multiple reading ,it did not set block count . so multiple
read failed because it don't know how many blocks to read.I set reg MCI_BLKR
BCNT bit.It is add in gen_atmel_mci.c.
I think that multiple reading was added to common code.
static int mci_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data
*data)
{
...
cmdr = mci_encode_cmd(cmd, data,error_flags);
/* Send the command */
+if ((cmd-cmdidx == MMC_CMD_READ_MULTIPLE_BLOCK) ||(cmd-cmdidx ==
MMC_CMD_WRITE_MULTIPLE_BLOCK))
+{
+ writel(data-blocks|mmc-read_bl_len16,mci-blkr);
+}
can't we write that register for all commands (remove the if)?
writel(cmd-cmdarg,mci-argr);
writel(cmdr,mci-cmdr);
...
MCI_BLKR should be added in mmc.h:
atmel_mci.h, I hope...
typedef struct atmel_mci {
/* reg Offset */
u32 cr; /* 0x00 */
u32 mr; /* 0x04 */
u32 dtor; /* 0x08 */
u32 sdcr; /* 0x0c */
u32 argr; /* 0x10 */
u32 cmdr; /* 0x14 */
- u32 _18;/* 0x18 */
+ u32 blkr; /* 0x18 */
...
Do you think it is correct?
Looks correct by the data sheet. Please verify function in both read and write
modes, make sure the number of blocks read or write is correct.
In that case,I will deliver a patch.
How does the patch for problem 1. look like?
And please run the patch through linux/scripts/checkpatch.pl, I see issues
in the samples you provided above.
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Question]AT91: MMC read and multiple read failed
Dear Song, Elen,
[snip]
static int mci_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct
mmc_data *data)
{
...
cmdr = mci_encode_cmd(cmd, data,error_flags);
/* Send the command */
+if ((cmd-cmdidx == MMC_CMD_READ_MULTIPLE_BLOCK) ||(cmd-cmdidx ==
MMC_CMD_WRITE_MULTIPLE_BLOCK))
+{
+ writel(data-blocks|mmc-read_bl_len16,mci-blkr);
+}
can't we write that register for all commands (remove the if)?
I guess no. Other place ,like sd_switch function use it ,but it is not a
real read or write.so do not need to set block count.I've tested,the code
will stuck.
writel(cmd-cmdarg,mci-argr);
writel(cmdr,mci-cmdr);
I do not think that the code gets stuck while writing a parameter register
with any value, since a command has not been issued to the chip.
It might be that the command gets stuck when an unsuitable value is in one of
the
parameter registers.
That itself would require to write another value to BLKR in case of such
commands
and not let the value be undefined or residual from a previous command.
[snip]
Another observation: it must be ensured that data-blocks is less than 65536!
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT91: EMK/TOP9000 board actualization
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
board/emk/top9000/top9000.c | 131 ++-
1 files changed, 116 insertions(+), 15 deletions(-)
diff --git a/board/emk/top9000/top9000.c b/board/emk/top9000/top9000.c
index 61dee62..92e8a9d 100644
--- a/board/emk/top9000/top9000.c
+++ b/board/emk/top9000/top9000.c
@@ -126,6 +126,7 @@ int board_mmc_getcd(u8 *cd, struct mmc *mmc)
int board_early_init_f(void)
{
struct at91_shdwn *shdwn = (struct at91_shdwn *)ATMEL_BASE_SHDWN;
+ struct at91_rstc *rstc = (struct at91_rstc *)ATMEL_BASE_RSTC;
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
/*
@@ -135,6 +136,13 @@ int board_early_init_f(void)
writel(AT91_SHDW_MR_WKMODE0H2L | AT91_SHDW_MR_WKMODE0L2H,
shdwn-mr);
+ /*
+* make sure the board can be reset by
+* low level on nRST
+*/
+ writel(AT91_RSTC_KEY | AT91_RSTC_MR_URSTEN,
+ rstc-mr);
+
/* Enable clocks for all PIOs */
writel((1 ATMEL_ID_PIOA) | (1 ATMEL_ID_PIOB) |
(1 ATMEL_ID_PIOC),
@@ -160,8 +168,14 @@ int board_early_init_f(void)
int board_init(void)
{
- /* arch number of TOP9000 Board */
- gd-bd-bi_arch_number = MACH_TYPE_TOP9000;
+ /* arch numbers of TOP9000 and baseboards */
+#if defined(CONFIG_EVAL9000)
+ gd-bd-bi_arch_number = MACH_TYPE_TOP9000_EVAL;
+#elif defined(CONFIG_SU9000)
+ gd-bd-bi_arch_number = MACH_TYPE_TOP9000_SU;
+#else
+ gd-bd-bi_arch_number = MACH_TYPE_TOP9000;
+#endif
/* adress of boot parameters */
gd-bd-bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
@@ -183,10 +197,97 @@ int board_init(void)
}
#ifdef CONFIG_MISC_INIT_R
+static int checksum(char *p)
+{
+ int sum = 0;
+ int i = 13;
+
+ while (i 0) {
+ if (*p '0' || *p '9')
+ return -1;
+ sum += *p;
+ if (!(i 1))
+ sum += 2 * *p;
+ --i;
+ ++p;
+ }
+ return sum % 10;
+}
+
int misc_init_r(void)
{
/* read 'factory' part of EEPROM */
- read_factory_r();
+ char buf[32];
+ char tag[4];
+ uint addr = CONFIG_SYS_FACT_OFFSET;
+ uint len = CONFIG_SYS_FACT_SIZE;
+ int have_top = 0;
+
+ /* read entries */
+ while (len = 16) {
+ /* read one entry */
+ if (eeprom_read(CONFIG_SYS_I2C_FACT_ADDR,
+ addr, (uchar *)buf, 16))
+ goto bailout;
+ addr += 16;
+ len -= 16;
+ /* get tag field */
+ tag[0] = buf[0];
+ tag[1] = buf[1];
+ tag[2] = buf[2];
+ tag[3] = 0;
+ /* skip entries with bad checksum */
+ if (checksum(buf + 3))
+ continue;
+ /* test for specific entries */
+ if (!strcmp(tag, TOP)) {
+ unsigned serialno;
+ /* retrieve serialnumber */
+ buf[15] = 0;
+ serialno = simple_strtoul(buf + 10, NULL, 10);
+ buf[10] = 0;
+ setenv(board_id, buf);
+ sprintf(buf, %05d, serialno);
+ setenv(serial#, buf);
+ sprintf(buf, 00:80:d9:0d:%02x:%02x,
+ serialno / 256,
+ serialno % 256);
+ setenv(ethaddr, buf);
+ have_top = 1;
+ } else if (!strcmp(tag, MA2)) {
+ unsigned serialno;
+ /* retrieve serialnumber */
+ buf[15] = 0;
+ serialno = simple_strtoul(buf + 10, NULL, 10);
+ sprintf(buf, 00:80:d9:0e:%02x:%02x,
+ serialno / 256,
+ serialno % 256);
+ setenv(eth2addr, buf);
+ } else if (!strcmp(tag, MA3)) {
+ unsigned serialno;
+ /* retrieve serialnumber */
+ buf[15] = 0;
+ serialno = simple_strtoul(buf + 10, NULL, 10);
+ sprintf(buf, 00:80:d9:0e:%02x:%02x,
+ serialno / 256,
+ serialno % 256);
+ setenv(eth3addr, buf);
+ } else if (!strcmp(tag, MA4)) {
+ unsigned serialno;
+ /* retrieve serialnumber */
+ buf[15] = 0;
+ serialno = simple_strtoul(buf + 10, NULL, 10);
+ sprintf(buf, 00:80:d9:0e:%02x:%02x,
+ serialno / 256
Re: [U-Boot] MCI support in U-Boot
Dear Song, Elen, Hello Reinhard, We planed to add MCI support in U-Boot. We found you once had a branch named “wip110202” which makes use of generic mci for AT91SAM9260. The commit id is 137f4defd “AT91:enable MMC on at91sam(9260/9g20/0xe)ek”. I tried that branch. It works well with generic mci command. But now it is gone. Do you have any future plan for the MCI support on AT91? We've done something on top of wip110202 to support other AT91 EK boards. Could you point what we shall continue to move on? A patch for MMC/SD making it work on at91sam9260 is here. Unfortunately I have mixed an unrelated change (to CONFIG_SYS_TEXT_BASE) into the same patch, I have to seperate that first before submitting to mainline u-boot. On that CONFIG_SYS_TEXT_BASE matter, I intended to move it to start of SDRAM, making sure u-boot relocation will not overlap (currently _TEXT_BASE is near end of SDRAM). I know that requires a change to at91bootstrap as well. What is your opinion on this? Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT91: enable MMC on at91sam(9260/9g20/0xe)ek
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
board/atmel/at91sam9260ek/at91sam9260ek.c | 33 +
include/configs/at91sam9260ek.h | 45 ++--
2 files changed, 62 insertions(+), 16 deletions(-)
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 682b922..784632e 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -23,6 +23,7 @@
*/
#include common.h
+#include mmc.h
#include asm/io.h
#include asm/arch/at91sam9260_matrix.h
#include asm/arch/at91sam9_smc.h
@@ -143,6 +144,38 @@ static void at91sam9260ek_macb_hw_init(void)
}
#endif
+#ifdef CONFIG_GENERIC_ATMEL_MCI
+/* this is a weak define that we are overriding */
+int board_mmc_init(bd_t *bd)
+{
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+
+ /* Enable MCI clock */
+ writel(1 ATMEL_ID_MCI, pmc-pcer);
+
+ /* Initialize MCI hardware */
+ at91_mci_hw_init();
+
+ /* This calls the atmel_mmc_init in gen_atmel_mci.c */
+ return atmel_mci_init((void *)ATMEL_BASE_MCI);
+}
+
+/* this is a weak define that we are overriding */
+int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+{
+ /*
+* the only currently existing use of this function
+* (fsl_esdhc.c) suggests this function must return
+* *cs = TRUE if a card is NOT detected - in most
+* cases the value of the pin when the detect switch
+* closes to GND
+*/
+ *cd = at91_get_gpio_value(CONFIG_SYS_MMC_CD_PIN) ? 1 : 0;
+ return 0;
+}
+
+#endif
+
int board_early_init_f(void)
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h
index 88578c6..f12e83a 100644
--- a/include/configs/at91sam9260ek.h
+++ b/include/configs/at91sam9260ek.h
@@ -75,6 +75,14 @@
#define CONFIG_BAUDRATE115200
#define CONFIG_SYS_BAUDRATE_TABLE {115200 , 19200, 38400, 57600, 9600 }
+/* SD/MMC card */
+#define CONFIG_MMC
+#define CONFIG_GENERIC_MMC
+#define CONFIG_GENERIC_ATMEL_MCI
+#define CONFIG_SYS_MMC_CD_PIN AT91_PIN_PC9
+#define CONFIG_CMD_MMC
+#define CONFIG_ATMEL_MCI_PORTB /* use port B on those boards */
+
/* LED */
#define CONFIG_AT91_LED
#defineCONFIG_RED_LED AT91_PIN_PA9/* this is the power
led */
@@ -127,21 +135,26 @@
(ATMEL_BASE_SRAM1 + 0x1000 - GENERATED_GBL_DATA_SIZE)
#endif
-/* DataFlash */
-#define CONFIG_ATMEL_DATAFLASH_SPI
-#define CONFIG_HAS_DATAFLASH 1
-#define CONFIG_SYS_SPI_WRITE_TOUT (5*CONFIG_SYS_HZ)
-#define CONFIG_SYS_MAX_DATAFLASH_BANKS 2
-#define CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS00xC000 /* CS0 */
-#define CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS10xD000 /* CS1 */
-#define AT91_SPI_CLK 1500
-
-#ifdef CONFIG_AT91SAM9G20EK
-#define DATAFLASH_TCSS (0x22 16)
-#else
-#define DATAFLASH_TCSS (0x1a 16)
-#endif
-#define DATAFLASH_TCHS (0x1 24)
+/*
+ * DataFlash
+ * cannot coexist with MMC due to shared pins.
+ */
+#ifndef CONFIG_MMC
+# define CONFIG_ATMEL_DATAFLASH_SPI
+# define CONFIG_HAS_DATAFLASH 1
+# define CONFIG_SYS_SPI_WRITE_TOUT (5*CONFIG_SYS_HZ)
+# define CONFIG_SYS_MAX_DATAFLASH_BANKS2
+# define CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS0 0xC000 /* CS0 */
+# define CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS1 0xD000 /* CS1 */
+# define AT91_SPI_CLK 1500
+
+# ifdef CONFIG_AT91SAM9G20EK
+# define DATAFLASH_TCSS (0x22 16)
+# else
+# define DATAFLASH_TCSS (0x1a 16)
+# endif
+# define DATAFLASH_TCHS(0x1 24)
+#endif /* ifndef CONFIG_MMC */
/* NAND flash */
#ifdef CONFIG_CMD_NAND
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][ATMEL] Fix author names
Dear Albert, thanks for fixing the names. My assumption of needing an afteernoon to get a new GIT up and running was too optimistic... After ubuntu 10.10 offered an automated upgrade to 11.04, I happyly accepted this and ended up with a broken installation that stops in grub, complaining there is no kernel... Now installing 11.04 from scratch... Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] Update at91sam9m10g45_devices.c to fix compile errors.
Dear Alex Waterman,
Move this file to the new ATMEL_BASE_* and ATMEL_ID_* defines.
Also fixed a problem appearing in the ethernet initialization where
the entire board was being reset, not just the ethernet controller.
This at least makes ethernet work on my board if the correct
environment (mac address, ip address, etc) is available on boot.
Signed-off-by: Alex Waterman awater...@dawning.com
---
.../cpu/arm926ejs/at91/at91sam9m10g45_devices.c| 26
++--
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9m10g45_devices.c
b/arch/arm/cpu/arm926ejs/at91/at91sam9m10g45_devices.c
index 4ad9b1f..9ef8966 100644
--- a/arch/arm/cpu/arm926ejs/at91/at91sam9m10g45_devices.c
+++ b/arch/arm/cpu/arm926ejs/at91/at91sam9m10g45_devices.c
@@ -26,42 +26,42 @@
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
#include asm/arch/gpio.h
-#include asm/arch/io.h
+#include asm/io.h
void at91_serial0_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTB, 19, 1); /* TXD0 */
at91_set_a_periph(AT91_PIO_PORTB, 18, 0); /* RXD0 */
- writel(1 AT91SAM9G45_ID_US0, pmc-pcer);
+ writel(1 ATMEL_ID_USART0, pmc-pcer);
}
void at91_serial1_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTB, 4, 1);/* TXD1 */
at91_set_a_periph(AT91_PIO_PORTB, 5, 0);/* RXD1 */
- writel(1 AT91SAM9G45_ID_US1, pmc-pcer);
+ writel(1 ATMEL_ID_USART1, pmc-pcer);
}
void at91_serial2_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTD, 6, 1);/* TXD2 */
at91_set_a_periph(AT91_PIO_PORTD, 7, 0);/* RXD2 */
- writel(1 AT91SAM9G45_ID_US2, pmc-pcer);
+ writel(1 ATMEL_ID_USART2, pmc-pcer);
}
void at91_serial3_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTB, 12, 0); /* DRXD */
at91_set_a_periph(AT91_PIO_PORTB, 13, 1); /* DTXD */
- writel(1 AT91_ID_SYS, pmc-pcer);
+ writel(1 ATMEL_ID_USART3, pmc-pcer);
}
If this is the debug UART, ID_USART3 is definitely wrong here. Also
following the example set up by at91sam9260_devives.c, this function
should be named at91_seriald_hw_init.
void at91_serial_hw_init(void)
There should be no such function left after rework.
@@ -86,14 +86,14 @@ void at91_serial_hw_init(void)
#ifdef CONFIG_ATMEL_SPI
void at91_spi0_hw_init(unsigned long cs_mask)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTB, 0, 0);/* SPI0_MISO */
at91_set_a_periph(AT91_PIO_PORTB, 1, 0);/* SPI0_MOSI */
at91_set_a_periph(AT91_PIO_PORTB, 2, 0);/* SPI0_SPCK */
/* Enable clock */
- writel(1 AT91SAM9G45_ID_SPI0, pmc-pcer);
+ writel(1 ATMEL_ID_SPI0, pmc-pcer);
if (cs_mask (1 0)) {
at91_set_a_periph(AT91_PIO_PORTB, 3, 0);
@@ -123,14 +123,14 @@ void at91_spi0_hw_init(unsigned long cs_mask)
void at91_spi1_hw_init(unsigned long cs_mask)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTB, 14, 0); /* SPI1_MISO */
at91_set_a_periph(AT91_PIO_PORTB, 15, 0); /* SPI1_MOSI */
at91_set_a_periph(AT91_PIO_PORTB, 16, 0); /* SPI1_SPCK */
/* Enable clock */
- writel(1 AT91SAM9G45_ID_SPI1, pmc-pcer);
+ writel(1 ATMEL_ID_SPI1, pmc-pcer);
if (cs_mask (1 0)) {
at91_set_a_periph(AT91_PIO_PORTB, 17, 0);
Those also miss the pull-up option like in at91sam9260_devices.c.
Please fix this file in the style done by at91sam9260_devices.c or
wait until I have done so.
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] Fix compile problem for some boards in the clock code.
Dear Alex Waterman,
Some boards use AT91_SLOW_CLOCK and other use
CONFIG_SYS_AT91_SLOW_CLOCK. This patch makes it so the arm926ejs
clock code will return which ever is set.
Signed-off-by: Alex Waterman awater...@dawning.com
---
arch/arm/cpu/arm926ejs/at91/clock.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/clock.c
b/arch/arm/cpu/arm926ejs/at91/clock.c
index 608af2c..0083bd2 100644
--- a/arch/arm/cpu/arm926ejs/at91/clock.c
+++ b/arch/arm/cpu/arm926ejs/at91/clock.c
@@ -57,7 +57,11 @@ static unsigned long at91_css_to_rate(unsigned long css)
{
switch (css) {
case AT91_PMC_MCKR_CSS_SLOW:
+#ifdef AT91_SLOW_CLOCK
+ return AT91_SLOW_CLOCK;
+#else
return CONFIG_SYS_AT91_SLOW_CLOCK;
+#endif
case AT91_PMC_MCKR_CSS_MAIN:
return gd-main_clk_rate_hz;
case AT91_PMC_MCKR_CSS_PLLA:
NAK. Compile problems for some boards shall not be fixed by hacks
into common source. Fix the board's definition file instead.
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] Adds wait to atmel_usart serial_init function
Dear Alex Waterman,
Adds a short busy loop wait to the atmel_usart.c serial_init()
function.
Signed-off-by: Alex Waterman awater...@dawning.com
---
drivers/serial/atmel_usart.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
index e326b2b..e355706 100644
--- a/drivers/serial/atmel_usart.c
+++ b/drivers/serial/atmel_usart.c
@@ -47,6 +47,8 @@ void serial_setbrg(void)
int serial_init(void)
{
+
+ volatile int i = 0;
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
writel(USART3_BIT(RSTRX) | USART3_BIT(RSTTX), usart-cr);
@@ -61,6 +63,10 @@ int serial_init(void)
| USART3_BF(NBSTOP, USART3_NBSTOP_1)),
usart-mr);
+ /* Short wait to let the serial port init. */
+ for (; i 1; i++)
+ ;
+
return 0;
}
1. Why is this delay needed in the first place?
Apparently it has not been required before.
2. Such a delay loop is highly dependant on toolchain,
cache and page situation and processor speed. It can not be
accepted as a solution. If a delay is really required here
and cannot be substituting by reading the UARTs status
register, udelay() must be used.
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] Updates the at91sam9m10g45ek.h config file.
Dear Alex Waterman, Moves to using newer defines and adds possible support for the second bank of RAM (if so desired). Also, some coding clean up: removed the needless define to 1s for defines that just act as flags. Signed-off-by: Alex Waterman awater...@dawning.com --- include/configs/at91sam9m10g45ek.h | 188 +-- 1 files changed, 113 insertions(+), 75 deletions(-) diff --git a/include/configs/at91sam9m10g45ek.h b/include/configs/at91sam9m10g45ek.h index de74dcf..5e02dde 100644 --- a/include/configs/at91sam9m10g45ek.h +++ b/include/configs/at91sam9m10g45ek.h @@ -27,48 +27,65 @@ #ifndef __CONFIG_H #define __CONFIG_H +/*#define DEBUG*/ + #define CONFIG_AT91_LEGACY +#define CONFIG_ATMEL_LEGACY /* ARM asynchronous clock */ -#define CONFIG_SYS_AT91_MAIN_CLOCK 1200/* from 12 MHz crystal */ +#define CONFIG_SYS_AT91_MAIN_CLOCK 1200 /* from 12 MHz crystal */ +#define AT91_SLOW_CLOCK 32768 Must be CONFIG_SYS_AT91_SLOW_CLOCK here. #define CONFIG_SYS_HZ1000 -#define CONFIG_ARM926EJS 1 /* This is an ARM926EJS Core*/ -#ifdef CONFIG_AT91SAM9M10G45EK -#define CONFIG_AT91SAM9M10G451 /* It's an Atmel AT91SAM9M10G45 SoC*/ -#else -#define CONFIG_AT91SAM9G45 1 /* It's an Atmel AT91SAM9G45 SoC*/ -#endif +#define CONFIG_AT91SAM9M10G45 +#define CONFIG_AT91FAMILY #define CONFIG_ARCH_CPU_INIT +#define CONFIG_BOARD_EARLY_INIT_F #undef CONFIG_USE_IRQ/* we don't need IRQ/FIQ stuff */ -#define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */ -#define CONFIG_SETUP_MEMORY_TAGS 1 -#define CONFIG_INITRD_TAG1 +#define CONFIGMDLINE_TAG /* enable passing of ATAGs */ +#define CONFIG_SETUP_MEMORY_TAGS +#define CONFIG_INITRD_TAG #define CONFIG_SKIP_LOWLEVEL_INIT +#define ATMEL_PIO_PORTS 5 /* 5 PIO ports. */ +#define CONFIG_SYS_SDRAM_BASE 0x7000 + /* * Hardware drivers */ -#define CONFIG_AT91_GPIO 1 -#define CONFIG_ATMEL_USART 1 +#define CONFIG_AT91_GPIO +#define CONFIG_ATMEL_USART #undef CONFIG_USART0 #undef CONFIG_USART1 #undef CONFIG_USART2 -#define CONFIG_USART31 /* USART 3 is DBGU */ +#define CONFIG_USART3/* USART 3 is DBGU */ +#define CONFIG_USART_BASE0xee00 /* Use the DBGU hardware. */ +#define CONFIG_USART_ID 10 Please follow the examples in at91sam9260ek.h There is no CONFIG_USARTx anymore. Just defining BASE and ID is sufficient. + +/* + * This needs to be defined for the OHCI code to work but it is defined as + * ATMEL_ID_UHPHS in the CPU specific header files. + */ +#define ATMEL_ID_UHP ATMEL_ID_UHPHS + +/* + * Specify the clock enable bit in the PMC_SCER register. + */ +#define ATMEL_PMC_UHPAT91SAM926x_PMC_UHP /* LCD */ -#define CONFIG_LCD 1 +#define CONFIG_LCD #define LCD_BPP LCD_COLOR8 -#define CONFIG_LCD_LOGO 1 +#define CONFIG_LCD_LOGO #undef LCD_TEST_PATTERN -#define CONFIG_LCD_INFO 1 -#define CONFIG_LCD_INFO_BELOW_LOGO 1 -#define CONFIG_SYS_WHITE_ON_BLACK1 -#define CONFIG_ATMEL_LCD 1 -#define CONFIG_ATMEL_LCD_RGB565 1 -#define CONFIG_SYS_CONSOLE_IS_IN_ENV 1 +#define CONFIG_LCD_INFO +#define CONFIG_LCD_INFO_BELOW_LOGO +#define CONFIG_SYS_WHITE_ON_BLACK +#define CONFIG_ATMEL_LCD +#define CONFIG_ATMEL_LCD_RGB565 +#define CONFIG_SYS_CONSOLE_IS_IN_ENV /* board specific(not enough SRAM) */ #define CONFIG_AT91SAM9G45_LCD_BASE 0x73E0 @@ -82,10 +99,10 @@ /* * BOOTP options */ -#define CONFIG_BOOTP_BOOTFILESIZE1 -#define CONFIG_BOOTP_BOOTPATH1 -#define CONFIG_BOOTP_GATEWAY 1 -#define CONFIG_BOOTP_HOSTNAME1 +#define CONFIG_BOOTP_BOOTFILESIZE +#define CONFIG_BOOTP_BOOTPATH +#define CONFIG_BOOTP_GATEWAY +#define CONFIG_BOOTP_HOSTNAME Thanks for removing the 1s ! /* * Command line configuration. @@ -98,35 +115,37 @@ #undef CONFIG_CMD_AUTOSCRIPT #undef CONFIG_CMD_LOADS -#define CONFIG_CMD_PING 1 -#define CONFIG_CMD_DHCP 1 -#define CONFIG_CMD_NAND 1 -#define CONFIG_CMD_USB 1 +#define CONFIG_CMD_PING +#define CONFIG_CMD_DHCP +#define CONFIG_CMD_NAND +#define CONFIG_CMD_USB /* SDRAM */ -#define CONFIG_NR_DRAM_BANKS 1 +#define CONFIG_NR_DRAM_BANKS 2 #define PHYS_SDRAM 0x7000 #define PHYS_SDRAM_SIZE 0x0800 /* 128 megs */ +#define PHYS_SDRAM_2 0x2000 +#define PHYS_SDRAM_SIZE_20x0800 /* 128 megs */ Preferably those numeric constants should be replaced by defines from a proper at91sam10g45.h /*
Re: [U-Boot] [PATCH 8/8] Updates the boards.cfg file
Dear Alex Waterman, Add the default generic at91sam9m10g45ek_config target to the new config system. Not all possible configurations of u-boot for the at91sam9m10g45ek are included yet. Add them as needed. Signed-off-by: Alex Waterman awater...@dawning.com --- boards.cfg |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/boards.cfg b/boards.cfg index dfefc3f..470bc18 100644 --- a/boards.cfg +++ b/boards.cfg @@ -72,6 +72,7 @@ netstar arm arm925t voicebluearm arm925t omap1510inn arm arm925t - ti aspenite arm arm926ejs - Marvellarmada100 +at91sam9m10g45ek arm arm926ejs at91sam9m10g45ek atmel at91 afeb9260 arm arm926ejs - - at91 at91cap9adk arm arm926ejs - atmel at91 at91sam9260ek_nandflash arm arm926ejs at91sam9260ek atmel at91at91sam9260ek:AT91SAM9260,SYS_USE_NANDFLASH Please sort by manufacturer. The at91sam9m10 would be behind any atmel at91sam926x boards. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master (updated)
Dear All, Le 01/07/2011 08:22, Andreas Bießmann a écrit : Dear all, Am 30.06.2011 um 13:16 schrieb Albert ARIBAUD: snip Andreas Bießmann (1): atstk100x: switch to common cfi driver Patchwork says: Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Saved mbix file starts like: From patchwork Tue Jun 28 14:15:58 2011 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [U-Boot] atstk100x: switch to common cfi driver Date: Tue, 28 Jun 2011 04:15:58 - From: =?utf-8?q?Andreas_Bie=C3=9Fmann_=3Cbiessmann=40corscience=2Ede=3E?= X-Patchwork-Id: 102387 Message-Id: 1309270558-25351-1-git-send-email-biessm...@corscience.de To: u-boot@lists.denx.de Cc: =?UTF-8?q?Andreas=20Bie=C3=9Fmann?= biessm...@corscience.de This patch removes the board implemenatation for flash driver which can now safely switched to the common cfi driver. Compile tested for all atstk100x boards, runtime tested on atstk1002. Signed-off-by: Andreas Bießmann biessm...@corscience.de snip andreas.de...@googlemail.com (8): at91rm9200.h: fix ATMEL_PMX_AA_TXD2 arm920t/at91: add clock.c arm920t/at91: use new clock.c features arm920t/at91: add at91rm9200_devices.c at91rm9200ek: use atmel_usart eb_cpux9k2: use atmel_usart cpuat91: use atmel_usart driver/serial: delete at91rm9200_usart Patchworks says: Signed-off-by: Andreas Bießmann biessm...@corscience.de Saved mbox file starts like: From patchwork Sun Jun 12 11:49:13 2011 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [U-Boot,atmel/next,3/7] arm920t/at91: add at91rm9200_devices.c Date: Sun, 12 Jun 2011 01:49:13 - From: =?utf-8?q?Andreas_Bie=C3=9Fmann_=3Candreas=2Edevel=40googlemail=2Ecom?= =?utf-8?q?=3E?= X-Patchwork-Id: 100078 Message-Id: 1307879357-97986-4-git-send-email-andreas.de...@googlemail.com To: u-boot@lists.denx.de, Reinhard Meyer u-b...@emk-elektronik.de This is a copy of arm926ejs/at91 api for perpherial initialisation. At the moment we just need the usart part of the api. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com why is in the second block my clear name replaced by email address (as in the commits in atmel/master) but the mails have correct (UTF8-formattet) clear name in 'From:'? Hmm... Sorry for not having noticed this. Apparently, it is already so in u-boot-atmel/. I have just created a branch out of the current u-boot/master, run 'pwclient get 100074' and 'git am', and your name appears as normal. Reinhard, what commands did you use to applie these patches? ALWAYS using patchworks: Download mbox, git-am the downloaded file. Apparently it makes a difference where the mail originated from. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master (updated)
Am 01.07.2011 12:05, schrieb Reinhard Meyer: ... why is in the second block my clear name replaced by email address (as in the commits in atmel/master) but the mails have correct (UTF8-formattet) clear name in 'From:'? Hmm... Sorry for not having noticed this. Apparently, it is already so in u-boot-atmel/. I have just created a branch out of the current u-boot/master, run 'pwclient get 100074' and 'git am', and your name appears as normal. Reinhard, what commands did you use to applie these patches? ALWAYS using patchworks: Download mbox, git-am the downloaded file. Apparently it makes a difference where the mail originated from. I downloaded pwclient, used 'pwclient get' and 'git-am' and get the same different results, depending on where the patch mail originated from. I used patches 100071 and 102387 to test. git is version 1.5.6.5 Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master (updated)
Am 01.07.2011 12:59, schrieb Albert ARIBAUD: Le 01/07/2011 12:05, Reinhard Meyer a écrit : why is in the second block my clear name replaced by email address (as in the commits in atmel/master) but the mails have correct (UTF8-formattet) clear name in 'From:'? Hmm... Sorry for not having noticed this. Apparently, it is already so in u-boot-atmel/. I have just created a branch out of the current u-boot/master, run 'pwclient get 100074' and 'git am', and your name appears as normal. Reinhard, what commands did you use to applie these patches? ALWAYS using patchworks: Download mbox, git-amthe downloaded file. Apparently it makes a difference where the mail originated from. If you mean it makes a difference whether you download the mbox or use pwclient, I just tried both and got exactly the same .patch file (except for an added From patchwork line at the top, due to the mbox format, and a git am of either file results in Andreas' full name and address being shown as author, as expected. Seems like either your and my .patch files differ in some way, or our setups (system, locale, git configuration). Reinhard Amicalement, I mean that it makes no difference whether I get the .patch files by mbox or by pwclient. What makes a difference is whether the patch was sent via googlemail or not. Apparently the subtle differences lead to different interpretation by git-am. If that is a configuration issue, I do now know where to look at. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master (updated)
Dear Andreas Bießmann, Dear Reinhard Meyer, Am 01.07.2011 12:47, schrieb Reinhard Meyer: Am 01.07.2011 12:05, schrieb Reinhard Meyer: snip git is version 1.5.6.5 can you please try a more recent version? (squeeze is out since February the 6th this year ;) my time is *very* limited right now, and I honestly am not up to updating git every few months... Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master (updated)
Dear Andreas Bießmann, Dear Reinhard Meyer, Am 01.07.2011 13:07, schrieb Reinhard Meyer: Dear Andreas Bießmann, Dear Reinhard Meyer, Am 01.07.2011 12:47, schrieb Reinhard Meyer: Am 01.07.2011 12:05, schrieb Reinhard Meyer: snip git is version 1.5.6.5 can you please try a more recent version? (squeeze is out since February the 6th this year ;) my time is *very* limited right now, like most of us ... and I honestly am not up to updating git every few months... But 1.5.6.5 is really old version. I do have an old virtual machine running lenny and give it a try. I will check, if git version is the root cause of this problem (what I think it is). You could - if you really have lenny installed - give lenny-backports repository a try: http://packages.debian.org/lenny-backports/git If I remember correctly, I installed that version not even a year ago. On another thought, I long wanted to move from a real machine to a virtual one, therefore I already have ubuntu-10.10 running in a VM and the git there is 1.7.1. I *just* have to move all other relevant files there ;) I think getting it *all* up would take a good afternoon ;) I'll see what I can do. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32: add grasshopper (ICnova AP7000) board
Dear Andreas Bießmann,
The grasshopper board is a neat avr32 evaluation kit produced by In-Circuit
GmbH.
...
+struct mmu_vm_range mmu_vmr_table[CONFIG_SYS_NR_VM_REGIONS] = {
+{
+.virt_pgno = CONFIG_SYS_FLASH_BASE PAGE_SHIFT,
+.nr_pages = CONFIG_SYS_FLASH_SIZE PAGE_SHIFT,
+.phys = (CONFIG_SYS_FLASH_BASE PAGE_SHIFT)
+| MMU_VMR_CACHE_NONE,
+}, {
+.virt_pgno = CONFIG_SYS_SDRAM_BASE PAGE_SHIFT,
+.nr_pages = EBI_SDRAM_SIZE PAGE_SHIFT,
+.phys = (CONFIG_SYS_SDRAM_BASE PAGE_SHIFT)
+| MMU_VMR_CACHE_WRBACK,
+},
+};
+
+static const struct sdram_config sdram_config = {
+/* Dual MT48LC16M16A2-7E (or equal) */
+.data_bits = SDRAM_DATA_32BIT,
+.row_bits = 13,
+.col_bits = 9,
+.bank_bits = 2,
+.cas= 2,
+.twr= 2,
+.trc= 7,
+.trp= 2,
+.trcd = 2,
+.tras = 4,
+.txsr = 7,
+/* 7.81 us */
+.refresh_period = (781 * (SDRAMC_BUS_HZ / 1000)) / 10,
+};
This patch is infested with 4/8 space indentations. Please fix to use tabs...
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] atstk100x: switch to common cfi driver
Dear Andreas Bießmann, This patch removes the board implemenatation for flash driver which can now safely switched to the common cfi driver. Compile tested for all atstk100x boards, runtime tested on atstk1002. Signed-off-by: Andreas Bießmann biessm...@corscience.de --- board/atmel/atstk1000/Makefile |1 - board/atmel/atstk1000/flash.c | 232 include/configs/atstk1002.h|9 +-- include/configs/atstk1003.h|9 +-- include/configs/atstk1004.h|9 +-- include/configs/atstk1006.h|9 +-- 6 files changed, 8 insertions(+), 261 deletions(-) delete mode 100644 board/atmel/atstk1000/flash.c Applied to u-boot-atmel/master. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH atmel/next 0/7] replace at91rm9200_usart by atmel_usart
Dear Andreas Bießmann, This series is an RFC for atmel/next! It should replace the current at91rm9200_usart driver by the common atmel_usart driver. This is tested on at91rm9200ek, there are patches included for the two other arm920t/at91 boards currently supported by u-boot. Jens, Eric feel free to test this stuff. Some of the patches where submitted before in another structure (move arm926ejs/at91/clock.c to arm/lib/at91 and use the API) - see http://patchwork.ozlabs.org/patch/99344/ and http://patchwork.ozlabs.org/patch/99550/ They both are superseded by this series. There may be some issues with one of the patches in this series if you reorder the patches. Therefore I would like to squash some of them together, if the review process shows that there are no other issues with it. There also might be some unnecessary reorering in some of the defines. This is subject to next version, but feel free to point them out. Andreas Bießmann (7): arm920t/at91: add clock.c arm920t/at91: use new clock.c features arm920t/at91: add at91rm9200_devices.c at91rm9200ek: use atmel_usart eb_cpux9k2: use atmel_usart cpuat91: use atmel_usart driver/serial: delete at91rm9200_usart arch/arm/cpu/arm920t/at91/Makefile |3 + arch/arm/cpu/arm920t/at91/at91rm9200_devices.c | 85 + arch/arm/cpu/arm920t/at91/clock.c | 160 arch/arm/cpu/arm920t/at91/cpu.c| 43 +++ arch/arm/cpu/arm926ejs/at91/clock.c| 35 +- arch/arm/include/asm/arch-at91/at91rm9200.h| 10 ++- arch/arm/include/asm/arch-at91/clk.h | 42 ++- board/BuS/eb_cpux9k2/cpux9k2.c |7 + board/atmel/at91rm9200ek/at91rm9200ek.c|7 + board/eukrea/cpuat91/cpuat91.c |8 ++ drivers/serial/Makefile|1 - drivers/serial/at91rm9200_usart.c | 126 --- include/configs/at91rm9200ek.h | 10 ++- include/configs/cpuat91.h | 12 +- include/configs/eb_cpux9k2.h | 10 +- 15 files changed, 379 insertions(+), 180 deletions(-) create mode 100644 arch/arm/cpu/arm920t/at91/at91rm9200_devices.c create mode 100644 arch/arm/cpu/arm920t/at91/clock.c create mode 100644 arch/arm/cpu/arm920t/at91/cpu.c delete mode 100644 drivers/serial/at91rm9200_usart.c Applied to u-boot-atmel/master. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] at91rm9200.h: fix ATMEL_PMX_AA_TXD2
Dear Andreas Bießmann, This patch sets the ATMEL_PMX_AA_TXD2 to the correct value. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com CC: Jens Scharsig js_at...@scharsoft.de CC: e...@eukrea.com --- changes since v1: - fix typo in commit message arch/arm/include/asm/arch-at91/at91rm9200.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied to u-boot-atmel/master. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][ATMEL] Fix compiler error for cpu at91sam9, if lowlevel init is enabled
Dear e...@bus-elektronik.de, * Fix compiler error for cpu at91sam9, if lowlevel init is enabled * use correct ATMEL_ name scheme to define ATMEL_BASE_SDRAMC Signed-off-by: Jens Scharsig --- arch/arm/include/asm/arch-at91/at91sam9_sdramc.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied to u-boot-atmel/master. Thanks, Reinhard PS: for better readability of Submitter it would be nice to have real names with the e-Mail address ;) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL request] u-boot-atmel/master
Dear Albert, The following changes since commit 385d2e0e93ca09fa9f763053afd03076b317228f: Matthias Weisser (1): arm: Update jadecpu board are available in the git repository at: git://git.denx.de/u-boot-atmel.git master Andreas Bießmann (1): atstk100x: switch to common cfi driver andreas.de...@googlemail.com (8): at91rm9200.h: fix ATMEL_PMX_AA_TXD2 arm920t/at91: add clock.c arm920t/at91: use new clock.c features arm920t/at91: add at91rm9200_devices.c at91rm9200ek: use atmel_usart eb_cpux9k2: use atmel_usart cpuat91: use atmel_usart driver/serial: delete at91rm9200_usart e...@bus-elektronik.de (1): Fix compiler error for cpu at91sam9, if lowlevel init is enabled arch/arm/cpu/arm920t/at91/Makefile |3 + arch/arm/cpu/arm920t/at91/at91rm9200_devices.c | 85 arch/arm/cpu/arm920t/at91/clock.c| 160 +++ arch/arm/cpu/arm920t/at91/cpu.c | 43 arch/arm/cpu/arm926ejs/at91/clock.c | 35 + arch/arm/include/asm/arch-at91/at91rm9200.h | 12 +- arch/arm/include/asm/arch-at91/at91sam9_sdramc.h |2 +- arch/arm/include/asm/arch-at91/clk.h | 42 - board/BuS/eb_cpux9k2/cpux9k2.c |7 + board/atmel/at91rm9200ek/at91rm9200ek.c |7 + board/atmel/atstk1000/Makefile |1 - board/atmel/atstk1000/flash.c| 232 -- board/eukrea/cpuat91/cpuat91.c |8 + drivers/serial/Makefile |1 - drivers/serial/at91rm9200_usart.c| 126 include/configs/at91rm9200ek.h | 10 +- include/configs/atstk1002.h |9 +- include/configs/atstk1003.h |9 +- include/configs/atstk1004.h |9 +- include/configs/atstk1006.h |9 +- include/configs/cpuat91.h| 12 +- include/configs/eb_cpux9k2.h | 10 +- 22 files changed, 389 insertions(+), 443 deletions(-) create mode 100644 arch/arm/cpu/arm920t/at91/at91rm9200_devices.c create mode 100644 arch/arm/cpu/arm920t/at91/clock.c create mode 100644 arch/arm/cpu/arm920t/at91/cpu.c delete mode 100644 board/atmel/atstk1000/flash.c delete mode 100644 drivers/serial/at91rm9200_usart.c Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 09/16] [Timer]Replace get_timer() usage in drivers/block/
Dear All,
Well I know i have asked this before, but I feel I should ask again
because I didn't like the answer much.
Imagine we change this code to:
ts = time_now_ms() + msec
do {
...
} while (time_since_ms(ts) 0);
That should be legal, right? But I don't think this can work since the
'since' functions return an unsigned.
[aside: this provides for another idiom that I think we talked about:
ts = time_future_ms(msec)
do {
...
} while (!time_passed(ts))
which I am not at all suggesting should be in the API :-)
end aside]
I still vouch for this concept, which is simple, clean, and easy to understand.
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-atmel/master
Dear Albert, The following changes since commit 0d8bc1c7b3caffd5626b6cf4888bfb5751f24041: Fabio Estevam (1): mx31pdk: Add DHCP command are available in the git repository at: git://git.denx.de/u-boot-atmel.git master Eric Benard (4): arm926ejs/at91/lowlevel_init.S: fix defines cpu9260/9G20: fix board support cpuat91: fix board support include/asm/arch-at91: update several .h files to ATMEL_xxx name scheme Jens Scharsig (1): update arm/at91rm9200 work with rework rework110202 Reinhard Meyer (3): AT91 rework: fix at91sam(9260/9g20/9xe)ek board port to build again: AT91 rework: fix TOP9000 files to build again ATMEL spi_dataflash driver - fix to build again Ryan Mallon (1): Add support for Bluewater Systems Snapper 9260/9G20 modules Sergey Lapin (1): Build fix/update of AFEB9260 andreas.de...@googlemail.com (2): at91_emac: fix compile warning macb: fix compile warning MAINTAINERS |5 + MAKEALL |3 - Makefile | 45 - arch/arm/cpu/arm920t/at91/reset.c|2 +- arch/arm/cpu/arm920t/at91/timer.c| 12 +- arch/arm/cpu/arm926ejs/at91/lowlevel_init.S | 24 ++-- arch/arm/include/asm/arch-at91/at91_matrix.h | 10 +- arch/arm/include/asm/arch-at91/at91_mc.h | 12 +- arch/arm/include/asm/arch-at91/at91_pio.h| 14 +- arch/arm/include/asm/arch-at91/at91_pmc.h| 10 +- arch/arm/include/asm/arch-at91/at91_rstc.h |2 +- arch/arm/include/asm/arch-at91/at91_wdt.h|2 +- arch/arm/include/asm/arch-at91/at91rm9200.h | 209 -- arch/arm/include/asm/arch-at91/at91sam9260.h |1 + arch/arm/include/asm/arch-at91/at91sam9261.h |1 + arch/arm/include/asm/arch-at91/at91sam9263.h |1 + arch/arm/include/asm/arch-at91/at91sam9_sdramc.h | 30 ++-- arch/arm/include/asm/arch-at91/at91sam9_smc.h| 12 +- board/BuS/eb_cpux9k2/cpux9k2.c | 52 +++--- board/afeb9260/afeb9260.c| 101 ++- board/atmel/at91rm9200ek/at91rm9200ek.c |4 +- board/atmel/at91rm9200ek/led.c | 22 ++- board/atmel/at91sam9260ek/at91sam9260ek.c| 127 +++-- board/atmel/at91sam9260ek/config.mk |1 - board/atmel/at91sam9260ek/led.c |8 +- board/bluewater/snapper9260/Makefile | 53 ++ board/bluewater/snapper9260/snapper9260.c| 169 + board/emk/top9000/top9000.c | 64 --- board/eukrea/cpu9260/cpu9260.c | 33 ++-- board/eukrea/cpu9260/led.c |6 +- board/eukrea/cpuat91/cpuat91.c |6 +- boards.cfg |9 + drivers/net/at91_emac.c | 44 +++--- drivers/net/macb.c |5 +- drivers/spi/atmel_dataflash_spi.c|3 +- include/configs/afeb9260.h | 78 + include/configs/at91rm9200ek.h |5 +- include/configs/at91sam9260ek.h | 107 +++- include/configs/cpu9260.h| 11 +- include/configs/eb_cpux9k2.h | 23 ++-- include/configs/snapper9260.h| 191 include/configs/top9000.h| 30 ++-- 42 files changed, 996 insertions(+), 551 deletions(-) delete mode 100644 board/atmel/at91sam9260ek/config.mk create mode 100644 board/bluewater/snapper9260/Makefile create mode 100644 board/bluewater/snapper9260/snapper9260.c create mode 100644 include/configs/snapper9260.h Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] about at91 board in uboot
Dear Lin, The following is the status XU Hong is reporting to me on u-boot-atmel/master. I saw it has been silent for 2 days. I don’t know if we could do something to help maintain all the boards. I will try to help allocate some of my people to handling missing parts for our EK. I send a message about 2 days ago, asking that the SoC relevant parts are changed in a manner consistent with the changes for the 9260, like in at91sam9260_devices.c, at91sam9260.h, at91sam9260_matrix.h. Once that is done, and added to u-boot-atmel/master, the board specific patches should be rebased on that and submitted. Since nobody did volunteer so far, I was going to edit the SoC specific parts and submit them, but unfortunately that could take some time (until next week maybe, I was going to start today with that, but have paid work to finish as well :) ) I am not fond of quick and dirty solutions here, the boards are not going to be removed with this u-boot release, but will be after if no progress is seen - but we do have progress here - so no need to panic. So lets do it in two distinct steps: 1. fix SoCs 2. fix boards 9261 soc ek have been merged to atmel branch. 9rl – v3 patches have been pushed out just now and shall be ok. 9263 – soc part has been merged into atmel branch. I’m asking the ek part. 9g45 - patches were sent by 3rd party. The SoC specific changes will/should be based before those patches, and will replace the current ones. --- Original Message: Dear Friends, I have received several different patches reworking at91sam*_devices.c and at91sam9*.h. Lokking at them, none of them is completely done the way the files for at91sam9260 are done. Examples: 9260, 9263: ATMEL_ID_USART0 9261: ATMEL_ID_US0 9260 uses the CONFIG_AT91_GPIO_PULLUP define, the others do not. 9261 still uses the CONFIG_USARTx defines. Please have a look at at91sam9260 as a reference. We do need a properly fixed SoC port for 9261, 9263 and the others before individual board ports can be fixed. Just because there is a sudden rush to get things fixed for the next release should NOT tempt us to get in interim versions. With Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] [V2] AT91: Makes AT91SAM9263 SoC build correctly against u-boot-atmel/master
Dear Hong Xu,
Rework for AT91SAM9263 SoC, makes it build again.
Based on the work for AT91SAM9260-EK.
Signed-off-by: Hong Xu hong...@atmel.com
---
arch/arm/cpu/arm926ejs/at91/lowlevel_init.S|2 +-
arch/arm/cpu/arm926ejs/at91/timer.c| 13 ++
arch/arm/include/asm/arch-at91/at91_spi.h |2 +-
arch/arm/include/asm/arch-at91/at91sam9263.h | 13 ++
.../arm/include/asm/arch-at91/at91sam9263_matrix.h | 146
++--
arch/arm/include/asm/arch-at91/at91sam9_sdramc.h |2 +-
6 files changed, 71 insertions(+), 107 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/timer.c
b/arch/arm/cpu/arm926ejs/at91/timer.c
index a087687..89a01ea 100644
--- a/arch/arm/cpu/arm926ejs/at91/timer.c
+++ b/arch/arm/cpu/arm926ejs/at91/timer.c
@@ -134,3 +134,16 @@ ulong get_tbclk(void)
{
return gd-timer_rate_hz;
}
+
+/*
+ * Reset the timer.
+ */
+void reset_timer(void)
+{
+ /* TODO: write this code. */
+}
+
+void reset_timer_masked(void)
+{
+ /* TODO: write this code. */
+}
NAK. Those functions were intentionally removed from at91/timer.c
quite a while ago.
If some other code requires them, it must be fixed there.
See also the discussion of the new timer API made recently.
Applied (without at91/timer.c changes) to u-boot-atmel/master.
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] [V2] AT91: Makes AT91SAM9261(9G10) SoC build correctly against u-boot-atmel/master
Dear Hong Xu,
Rework for AT91SAM9261(9G10) SoC, makes it build again.
Based on the work for AT91SAM9260-EK.
Signed-off-by: Hong Xu hong...@atmel.com
---
arch/arm/cpu/arm926ejs/at91/at91sam9261_devices.c | 45 +---
arch/arm/include/asm/arch-at91/at91_spi.h |2 +-
arch/arm/include/asm/arch-at91/at91sam9261.h |1 +
.../arm/include/asm/arch-at91/at91sam9261_matrix.h | 77
+---
4 files changed, 56 insertions(+), 69 deletions(-)
diff --git a/arch/arm/include/asm/arch-at91/at91_spi.h
b/arch/arm/include/asm/arch-at91/at91_spi.h
index c520e89..afe724d 100644
--- a/arch/arm/include/asm/arch-at91/at91_spi.h
+++ b/arch/arm/include/asm/arch-at91/at91_spi.h
@@ -33,7 +33,7 @@ typedef struct at91_spi {
at91_pdc_t pdc;
} at91_spi_t;
-#ifdef CONFIG_AT91_LEGACY
+#ifdef CONFIG_ATMEL_LEGACY
This was already fixed by another patch. But the endif statement was not...
#define AT91_SPI_CR 0x00/* Control Register */
#define AT91_SPI_SPIEN (1 0) /* SPI
Enable */
After fixing at91_spi.h applied to u-boot-atmel/master
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] [V2] AT91: Makes AT91SAM9RL SoC build correctly against u-boot-atmel/master
Dear Hong Xu,
Rework for AT91SAM9RL SoC, makes it build again.
Based on the work for AT91SAM9260-EK.
Signed-off-by: Hong Xu hong...@atmel.com
---
arch/arm/cpu/arm926ejs/at91/at91sam9rl_devices.c | 26 ++--
arch/arm/include/asm/arch-at91/at91_spi.h |2 +-
arch/arm/include/asm/arch-at91/at91sam9rl.h| 176
++--
arch/arm/include/asm/arch-at91/at91sam9rl_matrix.h | 121 +-
4 files changed, 141 insertions(+), 184 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9rl_devices.c
b/arch/arm/cpu/arm926ejs/at91/at91sam9rl_devices.c
index 4f570f4..c8d19f8 100644
--- a/arch/arm/cpu/arm926ejs/at91/at91sam9rl_devices.c
+++ b/arch/arm/cpu/arm926ejs/at91/at91sam9rl_devices.c
@@ -23,45 +23,45 @@
*/
#include common.h
+#include asm/io.h
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
#include asm/arch/gpio.h
-#include asm/arch/io.h
void at91_serial0_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTA, 6, 1);/* TXD0 */
at91_set_a_periph(AT91_PIO_PORTA, 7, 0);/* RXD0 */
- writel(1 AT91SAM9RL_ID_US0, pmc-pcer);
+ writel(1 ATMEL_ID_US0, pmc-pcer);
}
void at91_serial1_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTA, 11, 1); /* TXD1 */
at91_set_a_periph(AT91_PIO_PORTA, 12, 0); /* RXD1 */
- writel(1 AT91SAM9RL_ID_US1, pmc-pcer);
+ writel(1 ATMEL_ID_US1, pmc-pcer);
}
void at91_serial2_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTA, 13, 1); /* TXD2 */
at91_set_a_periph(AT91_PIO_PORTA, 14, 0); /* RXD2 */
- writel(1 AT91SAM9RL_ID_US2, pmc-pcer);
+ writel(1 ATMEL_ID_US2, pmc-pcer);
}
-void at91_serial3_hw_init(void)
+void at91_seriald_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTA, 21, 0); /* DRXD */
at91_set_a_periph(AT91_PIO_PORTA, 22, 1); /* DTXD */
- writel(1 AT91_ID_SYS, pmc-pcer);
+ writel(1 ATMEL_ID_SYS, pmc-pcer);
}
void at91_serial_hw_init(void)
@@ -79,21 +79,21 @@ void at91_serial_hw_init(void)
#endif
#ifdef CONFIG_USART3 /* DBGU */
- at91_serial3_hw_init();
+ at91_seriald_hw_init();
#endif
No at91_serial_hw_init, no CONFIG_USARTx anymore.
You fixed that correctly at other SoCs, why not here?
}
#ifdef CONFIG_HAS_DATAFLASH
void at91_spi0_hw_init(unsigned long cs_mask)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTA, 25, 0); /* SPI0_MISO */
at91_set_a_periph(AT91_PIO_PORTA, 26, 0); /* SPI0_MOSI */
at91_set_a_periph(AT91_PIO_PORTA, 27, 0); /* SPI0_SPCK */
/* Enable clock */
- writel(1 AT91SAM9RL_ID_SPI, pmc-pcer);
+ writel(1 ATMEL_ID_SPI, pmc-pcer);
if (cs_mask (1 0)) {
at91_set_a_periph(AT91_PIO_PORTA, 28, 1);
diff --git a/arch/arm/include/asm/arch-at91/at91_spi.h
b/arch/arm/include/asm/arch-at91/at91_spi.h
index c520e89..afe724d 100644
--- a/arch/arm/include/asm/arch-at91/at91_spi.h
+++ b/arch/arm/include/asm/arch-at91/at91_spi.h
@@ -33,7 +33,7 @@ typedef struct at91_spi {
at91_pdc_t pdc;
} at91_spi_t;
-#ifdef CONFIG_AT91_LEGACY
+#ifdef CONFIG_ATMEL_LEGACY
That is already fixed.
#define AT91_SPI_CR 0x00/* Control Register */
#define AT91_SPI_SPIEN (1 0) /* SPI
Enable */
diff --git a/arch/arm/include/asm/arch-at91/at91sam9rl.h
b/arch/arm/include/asm/arch-at91/at91sam9rl.h
index 8eb0d4f..7e3a029 100644
--- a/arch/arm/include/asm/arch-at91/at91sam9rl.h
+++ b/arch/arm/include/asm/arch-at91/at91sam9rl.h
@@ -14,117 +14,109 @@
#ifndef AT91SAM9RL_H
#define AT91SAM9RL_H
+#define CONFIG_ARM926EJS /* ARM926EJS Core */
+#define CONFIG_AT91FAMILY/* it's a member of AT91 */
/*
* Peripheral identifiers/interrupts.
*/
-#define AT91_ID_FIQ 0 /* Advanced Interrupt Controller (FIQ)
*/
-#define AT91_ID_SYS 1 /* System Controller */
-#define AT91SAM9RL_ID_PIOA 2 /* Parallel IO Controller A */
-#define AT91SAM9RL_ID_PIOB 3 /* Parallel IO Controller B */
-#define AT91SAM9RL_ID_PIOC 4 /* Parallel IO Controller C */
-#define
Re: [U-Boot] [PATCH 2/2] [V2] AT91: Makes AT91SAM9261(9G10)-EK build correctly against u-boot-atmel/master
Dear Hong Xu, Rework for AT91SAM9261(9G10)-EK, makes it build again. Based on the work for AT91SAM9260-EK. Signed-off-by: Hong Xu hong...@atmel.com --- Makefile | 23 - board/atmel/at91sam9261ek/at91sam9261ek.c | 136 +++-- board/atmel/at91sam9261ek/config.mk |1 - board/atmel/at91sam9261ek/led.c |7 +- boards.cfg|6 ++ include/configs/at91sam9261ek.h | 81 ++ 6 files changed, 128 insertions(+), 126 deletions(-) delete mode 100644 board/atmel/at91sam9261ek/config.mk Applied to u-boot-atmel/master, Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4][AT91][ARM] Build fix/update of AFEB9260
Dear Sergey Lapin, Make AFEB9260 build again. Based on fix for AT91SAM9260EK. Signed-off-by: Sergey Lapin sla...@ossfans.org --- Fixed unneeded 1s in defines in board configuration Removed most undefs in board configuration Setting SoC name in board configuration board/afeb9260/afeb9260.c | 101 --- include/configs/afeb9260.h | 78 ++ 2 files changed, 97 insertions(+), 82 deletions(-) Applied to u-boot-atmel/master, Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM/ATMEL/AT91: rework SoCs 9261/9263 and others
Dear Friends, I have received several different patches reworking at91sam*_devices.c and at91sam9*.h. Lokking at them, none of them is completely done the way the files for at91sam9260 are done. Examples: 9260, 9263: ATMEL_ID_USART0 9261: ATMEL_ID_US0 9260 uses the CONFIG_AT91_GPIO_PULLUP define, the others do not. 9261 still uses the CONFIG_USARTx defines. Please have a look at at91sam9260 as a reference. We do need a properly fixed SoC port for 9261, 9263 and the others before individual board ports can be fixed. Just because there is a sudden rush to get things fixed for the next release should NOT tempt us to get in interim versions. With Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makes AT91SAM9261-EK build correctly against the mainline HEAD
Dear Hong Xu, Rework for AT91SAM9261-EK, makes it build again. Based on the work for AT91SAM9260-EK. Signed-off-by: voicevoice.s...@atmel.com Signed-off-by: Hong Xuhong...@atmel.com --- Makefile | 23 arch/arm/cpu/arm926ejs/at91/at91sam9261_devices.c | 45 +++ arch/arm/include/asm/arch-at91/at91_spi.h |2 +- arch/arm/include/asm/arch-at91/at91sam9261.h |2 +- .../arm/include/asm/arch-at91/at91sam9261_matrix.h | 77 +-- board/atmel/at91sam9261ek/at91sam9261ek.c | 136 ++- board/atmel/at91sam9261ek/config.mk|1 - board/atmel/at91sam9261ek/led.c|7 +- boards.cfg |6 + include/configs/at91sam9261ek.h| 81 +++- 10 files changed, 184 insertions(+), 196 deletions(-) delete mode 100644 board/atmel/at91sam9261ek/config.mk Could you please make separate patches for the parts that fix the SoC itself, and for what fixes the board? I by now have several similar SoC fixes gotten as patches, I have to somehow make the best of them I might have to pick parts from each of them. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makes AT91SAM9261-EK build correctly against the mainline HEAD
Dear Hong Xu, and please rebase against the u-boot-atmel/master, there are already a few patches on it that yours might be relying on. For the time being, we should at first fix the SoC files, and later when that all is on top of tree, fix the boards. Otherwise we'll get a lot of mess and non-applying patches. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Atmel pull request?
Dear Wolfgang Denk, Dear Reinhard, what are the chances to see a pull request for the Atmel boards any time soon? As is, theyu still form the majority of broken ARM boards, and I would like to get the release out as soon as possible. So I'd appreciate if we could have your pull request ASAP, then I could make a -rc3 and allow for a few days of testing, before releasing v2011.06. I will be checking the latest patches on the list by today, accept them if possible and issue a pull to Albert after that. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] include/asm/arch-at91: update several .h files to ATMEL_xxx name scheme
Dear Eric Bénard, Signed-off-by: Eric Bénard e...@eukrea.com --- arch/arm/include/asm/arch-at91/at91_matrix.h | 10 +++--- arch/arm/include/asm/arch-at91/at91_rstc.h |2 +- arch/arm/include/asm/arch-at91/at91_wdt.h|2 +- arch/arm/include/asm/arch-at91/at91sam9_sdramc.h | 30 +++--- arch/arm/include/asm/arch-at91/at91sam9_smc.h| 12 5 files changed, 28 insertions(+), 28 deletions(-) diff --git a/arch/arm/include/asm/arch-at91/at91_matrix.h b/arch/arm/include/asm/arch-at91/at91_matrix.h index f99b1d4..a9ba9e9 100644 --- a/arch/arm/include/asm/arch-at91/at91_matrix.h +++ b/arch/arm/include/asm/arch-at91/at91_matrix.h Several lines are longer than 80 chars. Can you fix this asap? I think the comments could be left away completely or at least shortened by removing the obvios SDAM Controller part. Before someone complains about this out of context: those defines are used by ASM and therefore no struct SoC access is possible in that case. Thank you, Reinhard +#define AT91_SDRAMC_MR (ATMEL_BASE_SDRAMC + 0x00) /* SDRAM Controller Mode Register */ +#define AT91_SDRAMC_TR (ATMEL_BASE_SDRAMC + 0x04) /* SDRAM Controller Refresh Timer Register */ +#define AT91_SDRAMC_CR (ATMEL_BASE_SDRAMC + 0x08) /* SDRAM Controller Configuration Register */ +#define AT91_SDRAMC_LPR (ATMEL_BASE_SDRAMC + 0x10) /* SDRAM Controller Low Power Register */ +#define AT91_SDRAMC_IER (ATMEL_BASE_SDRAMC + 0x14) /* SDRAM Controller Interrupt Enable Register */ +#define AT91_SDRAMC_IDR (ATMEL_BASE_SDRAMC + 0x18) /* SDRAM Controller Interrupt Disable Register */ +#define AT91_SDRAMC_IMR (ATMEL_BASE_SDRAMC + 0x1C) /* SDRAM Controller Interrupt Mask Register */ +#define AT91_SDRAMC_ISR (ATMEL_BASE_SDRAMC + 0x20) /* SDRAM Controller Interrupt Status Register */ +#define AT91_SDRAMC_MDR (ATMEL_BASE_SDRAMC + 0x24) /* SDRAM Memory Device Register */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] cpu9260/9G20: fix board support
Am 07.06.2011 10:48, schrieb Eric Bénard: Signed-off-by: Eric Bénard e...@eukrea.com --- MAKEALL|2 -- Makefile |8 board/eukrea/cpu9260/cpu9260.c | 33 - board/eukrea/cpu9260/led.c |6 +++--- include/configs/cpu9260.h | 11 +-- 5 files changed, 24 insertions(+), 36 deletions(-) Applied to u-boot-atmel/master. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] cpuat91: fix board support
Am 07.06.2011 10:48, schrieb Eric Bénard: Signed-off-by: Eric Bénard e...@eukrea.com --- MAKEALL|1 - board/eukrea/cpuat91/cpuat91.c |6 +++--- 2 files changed, 3 insertions(+), 4 deletions(-) Applied to u-boot-atmel/master. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] include/asm/arch-at91: update several .h files to ATMEL_xxx name scheme
Am 09.06.2011 10:25, schrieb Eric Bénard: Hi Reinhard, On 09/06/2011 10:17, Reinhard Meyer wrote: Several lines are longer than 80 chars. Can you fix this asap? I think the comments could be left away completely or at least shortened by removing the obvios SDAM Controller part. These lines are already over 80 char before this patch which only fix the define names : please apply this patch as is. I am not sure about current policy about this... In today's u-boot, linux's checkpatch.pl finds 483 over 80 in arch/arm/include/asm/arch-at91/ so I don't think this patch creates more trouble here. Applied to u-boot-atmel/master. Thanks, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2][ARM][AT91] Build fix/update of AFEB9260
Dear Sergey Lapin, Make AFEB9260 build again. Based on fix for AT91SAM9260EK. Signed-off-by: Sergey Lapin sla...@ossfans.org --- Cleaned-up a bit board/afeb9260/afeb9260.c | 103 --- boards.cfg |2 +- include/configs/afeb9260.h | 28 +--- 3 files changed, 79 insertions(+), 54 deletions(-) ... diff --git a/boards.cfg b/boards.cfg index ac20c81..a187a9f 100644 --- a/boards.cfg +++ b/boards.cfg @@ -72,7 +72,7 @@ netstar arm arm925t voicebluearm arm925t omap1510inn arm arm925t - ti aspenite arm arm926ejs - Marvellarmada100 -afeb9260 arm arm926ejs - - at91 +afeb9260 arm arm926ejs - - at91afeb9260:AT91SAM9260 at91cap9adk arm arm926ejs - atmel at91 at91sam9260ek_nandflash arm arm926ejs at91sam9260ek atmel at91at91sam9260ek:AT91SAM9260,SYS_USE_NANDFLASH at91sam9260ek_dataflash_cs0 arm arm926ejs at91sam9260ek atmel at91at91sam9260ek:AT91SAM9260,SYS_USE_DATAFLASH_CS0 Does not the afeb9260 have a manufacturer? And if it is not planned to be available with other Atmel SoCs, it is not necessary to have the AT91SAM9260 in the boards.cfg file. See also below. diff --git a/include/configs/afeb9260.h b/include/configs/afeb9260.h index 36a2a46..9114a52 100644 --- a/include/configs/afeb9260.h +++ b/include/configs/afeb9260.h @@ -25,12 +25,19 @@ #ifndef __CONFIG_H #define __CONFIG_H +#include asm/arch/hardware.h -#define CONFIG_AT91_LEGACY +#define CONFIG_SYS_TEXT_BASE 0x21f0 /* ARM asynchronous clock */ #define CONFIG_SYS_AT91_MAIN_CLOCK 18429952/* from 18.432 MHz crystal */ -#define CONFIG_SYS_HZ1000 +#define CONFIG_SYS_AT91_SLOW_CLOCK 32768 +#define CONFIG_SYS_HZ1000 + +#define CONFIG_BOARD_EARLY_INIT_F +#define CONFIG_DISPLAY_CPUINFO + + #define CONFIG_AT91SAM9260 1 /* It's an Atmel AT91SAM9260 SoC*/ This should lead to a double definition warning. See above. Also, please do not use 1 if no numerical value is intended for the define. Important: if you define the SoC type in this file, it must be before hardware.h is included. #define CONFIG_AFEB9260 1 /* on an AFEB9260 Board */ Please remove the 1 here. Fix further down as well. @@ -46,8 +53,14 @@ /* * Hardware drivers */ +#define CONFIG_ATMEL_LEGACY #define CONFIG_AT91_GPIO 1 No 1 here. +#define CONFIG_AT91_PULLUP 1 This 1 is required. OK. + + Avoid double empty lines. #define CONFIG_ATMEL_USART 1 No 1 here. +#define CONFIG_USART_BASEATMEL_BASE_DBGU +#define CONFIG_USART_ID ATMEL_ID_SYS #undef CONFIG_USART0 #undef CONFIG_USART1 #undef CONFIG_USART2 Please, no #undef's. Fix further down as well. @@ -82,8 +95,8 @@ /* SDRAM */ #define CONFIG_NR_DRAM_BANKS 1 -#define PHYS_SDRAM 0x2000 -#define PHYS_SDRAM_SIZE 0x0400 /* 64 megs */ +#define CONFIG_SYS_SDRAM_BASEATMEL_BASE_CS1 +#define CONFIG_SYS_SDRAM_SIZE0x0400 /* 64 megs */ /* DataFlash */ #define CONFIG_ATMEL_DATAFLASH_SPI @@ -100,7 +113,7 @@ #ifdef CONFIG_CMD_NAND #define CONFIG_NAND_ATMEL #define CONFIG_SYS_MAX_NAND_DEVICE 1 -#define CONFIG_SYS_NAND_BASE 0x4000 +#define CONFIG_SYS_NAND_BASE ATMEL_BASE_CS3 #define CONFIG_SYS_NAND_DBW_81 /* our ALE is AD21 */ #define CONFIG_SYS_NAND_MASK_ALE (1 21) @@ -134,12 +147,14 @@ #define CONFIG_SYS_LOAD_ADDR 0x2100 /* load address */ -#define CONFIG_SYS_MEMTEST_START PHYS_SDRAM +#define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE #define CONFIG_SYS_MEMTEST_END 0x21e0 #undef CONFIG_SYS_USE_DATAFLASH_CS0 #define CONFIG_SYS_USE_DATAFLASH_CS1 1 #undef CONFIG_SYS_USE_NANDFLASH +#define CONFIG_SYS_INIT_SP_ADDR (ATMEL_BASE_SRAM1 + 0x1000 -\ + GENERATED_GBL_DATA_SIZE) /* bootstrap + u-boot + env + linux in dataflash on CS1 */ #define CONFIG_ENV_IS_IN_DATAFLASH 1 Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] at91: move a/a/c/arm926ejs/at91/clock.c - a/a/lib/at91
Dear Andreas Bießmann, The at91/clock.c is copied from linux kernel and has support for both arm920t and arm926ejs core devices. Therefore this patch moves this generic at91/clock.c to a new place at arch/arm/lib/at91 to be used from at91 family devices. We build a new libat91-common.o to provide the required symbols to both cpu types. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- Makefile |3 + arch/arm/cpu/arm926ejs/at91/Makefile |1 - arch/arm/cpu/arm926ejs/at91/clock.c | 215 -- arch/arm/lib/at91/Makefile | 45 +++ arch/arm/lib/at91/clock.c| 215 ++ 5 files changed, 263 insertions(+), 216 deletions(-) delete mode 100644 arch/arm/cpu/arm926ejs/at91/clock.c create mode 100644 arch/arm/lib/at91/Makefile create mode 100644 arch/arm/lib/at91/clock.c Please use the git-mv command to move the file clock.c. On any account, we should discuss about opening a subdir lib scheme first. Currently arch/arm/lib does not have any subdirectories. I _do_ see the problems of the current ARM directory structure which makes the ARM core a more important criteria than SoC family especially in the Atmel context where the SoCs have identical peripheral blocks but can have different ARM cores. Since that change goes outside the Atmel directory domain, I consider this an RFC. Albert is already on CC. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
