June 2005 - U-Boot

[U-Boot-Users] i.MX support for scb9328 cleaned up
by Konstantin Kletschke 12 Oct '05

12 Oct '05

I cleaned up board support for the scb9328 board. I did changes to the scb9328.h, it is very much more readable more. Many timings have been tuned, the system is much faster now. Also the board/scb9328/flash.c is removed, the patch will delete it! The cfi_flash.c is used now. If anybody is interested, it is at http://www.ludenkalle.de/u-boot-1.1.2-imx1/u-boot-1.1.2-imx1.diff It contains the code unlocking intel k3 devices. splitdiff output is at http://www.ludenkalle.de/u-boot-1.1.2-imx1/u-boot-1.1.2_* (directory viewing on http://www.ludenkalle.de/u-boot-1.1.2-imx1/ is allowed). May be I could get advice what still looks odd so I can fix it, so the stuff could be apllied. Or it can be applied as is... Regards, Konsti -- GPG KeyID EF62FCEF Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF

3 12

[U-Boot-Users] (no subject)
by Andy Fleming 09 Oct '05

09 Oct '05

Here's a patch which puts the PHYs for the 3rd and 4th eTSECS into RGMII mode on the 8548 CDS.

2 1

[U-Boot-Users] NS7520 processor support patch
by Arthur Shipkowski 09 Oct '05

09 Oct '05

This patch adds support for the NS7520 processor as CONFIG_NETARM_NS7520. The patch adds its support to the current Net+ARM related files when possible. The sole exception is the Ethernet driver, because the Ethernet support is not like that on the prior Net+ARM parts nor like that on the NS9750. This patch has been tested against current CVS with MAKEALL arm. CHANGELOG: * Patch by Art Shipkowski, 12 May 2005: Implemented support for the NetSilicon NS7520 processor. Art Shipkowski Videon Central Software Engineer (814)235-1111 x307 art(a)videon-central.com

2 1

[U-Boot-Users] cfi_flash.c bug regarding intel k3 devices
by Konstantin Kletschke 09 Oct '05

09 Oct '05

Hi! cfi_flash.c handles intel k3 devices not correct, they power up with all sectors locked. Similair to flash_unlock_seq for amd devices, there must exist a flash_unlock_seq_intelk3 to do this for intel devices. --- u-boot-1.1.2/drivers/cfi_flash.c 2004-12-18 23:35:45.000000000 +0100 +++ u-boot-1.1.2-imx1/drivers/cfi_flash.c 2005-05-12 15:59:06.000000000 +0200 @@ -111,6 +111,9 @@ #define AMD_ADDR_START 0x555 #define AMD_ADDR_ACK 0x2AA +#define INTEL_CMD_UNLOCK_START 0x60 +#define INTEL_CMD_UNLOCK_ACK 0xD0 + #define FLASH_OFFSET_CFI 0x55 #define FLASH_OFFSET_CFI_RESP 0x10 #define FLASH_OFFSET_PRIMARY_VENDOR 0x13 @@ -180,6 +183,7 @@ static void flash_make_cmd (flash_info_t * info, uchar cmd, void *cmdbuf); static void flash_write_cmd (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static void flash_unlock_seq (flash_info_t * info, flash_sect_t sect); +static void flash_unlock_seq_intelk3 (flash_info_t * info, flash_sect_t sect); static int flash_isequal (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static int flash_isset (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static int flash_toggle (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); @@ -239,7 +243,6 @@ } #endif - /*----------------------------------------------------------------------- * read a character at a port width address */ @@ -397,6 +400,7 @@ switch (info->vendor) { case CFI_CMDSET_INTEL_STANDARD: case CFI_CMDSET_INTEL_EXTENDED: + flash_unlock_seq_intelk3 (info, sect); flash_write_cmd (info, sect, 0, FLASH_CMD_CLEAR_STATUS); flash_write_cmd (info, sect, 0, FLASH_CMD_BLOCK_ERASE); flash_write_cmd (info, sect, 0, FLASH_CMD_ERASE_CONFIRM); @@ -858,6 +862,12 @@ flash_write_cmd (info, sect, AMD_ADDR_ACK, AMD_CMD_UNLOCK_ACK); } +static void flash_unlock_seq_intelk3 (flash_info_t * info, flash_sect_t sect) +{ + flash_write_cmd (info, sect, 0, INTEL_CMD_UNLOCK_START); + flash_write_cmd (info, sect, 0, INTEL_CMD_UNLOCK_ACK); +} + /*----------------------------------------------------------------------- */ static int flash_isequal (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd) May be there must be added an "if" to filter intel k3 devices only, can somebody confirm this? Regards, Konsti -- GPG KeyID EF62FCEF Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF

3 6

[U-Boot-Users] [PATCH] - OMAP242x fix for GP device booting.
by Woodruff, Richard 06 Oct '05

06 Oct '05

Hello, This patch fixes booting on OMAP242x GP devices, and it unlocks a GP SRAM suitable for DSS subsystem access. One other minor change is to the DDR's DLL count value when used in unlock mode. This change allows standard low speed operation for 100MHz DDR's. Regards, Richard W.

2 2

[U-Boot-Users] [PATCH 4/4] add csb637 (at91rm9200) support
by Anders Larsen 05 Oct '05

05 Oct '05

Hi, this patch switches the at91rm9200 to asynchronous clocking mode after initialization (it would otherwise stay in FastBus mode which is the _slowest_ clock mode). This lets the core run at full speed when not doing bus accesses, increasing overall performance by a factor of four. The performance difference between asynchronous ans synchronous clocking mode as measured with nbench 2.2.2 disappears in the statistical noise; since asynchronous clocking mode imposes less restrictions on the clock frequencies it is the mode of choice. This patch replaces my similar patch from 2005-04-29. Changelog: * patch by Anders Larsen, 2005-05-03 set the at91rm9200 to asynchronous clocking mode Cheers Anders

2 1

[U-Boot-Users] [PATCH 4/4] add csb637 (at91rm9200) support
by Anders Larsen 05 Oct '05

05 Oct '05

Hi, this patch switches the at91rm9200 to synchronous clock mode after initialization (it would otherwise stay in FastBus mode which is the _slowest_ clock mode). This lets the core run at full speed when not doing bus accesses, increasing overall performance by a factor of four. Changelog: * patch by Anders Larsen, 2004-04-29 set the at91rm9200 clock to synchronous mode Cheers Anders

3 3

[U-Boot-Users] [PATCH 3/4] add csb637 (at91rm9200) support
by Anders Larsen 05 Oct '05

05 Oct '05

Hi, this patch adds basic support for the Cogent csb637 AT91RM9200-based board. This implementation loads u-boot directly from NOR flash and does not support dataflash, CF, MMC. The on-board LCD controller is not supported (yet). The configuration matches the version I got, that is, 8MiB of CFI flash and 64MiB of SDRAM (the board is available with other memory options, too). Changelog: * patch by Anders Larsen, 2004-04-29 add support for Cogent csb637 Cheers Anders

2 1

[U-Boot-Users] [PATCH 2/4] add csb637 (at91rm9200) support
by Anders Larsen 05 Oct '05

05 Oct '05

Hi, this patch fixes two bugs in dm9161.c; - in dm9161_InitPhy the interrupts were enabled instead of disabled - in dm9161_AutoNegotiate the PHY was disconnected from the wire and never re-connected (it seems this function is never called). Changelog: * patch by Anders Larsen, 2005-04-29 fix dm9161.c initialization Cheers Anders

2 1

[U-Boot-Users] [PATCH 1/4][RESEND] add csb637 (at91rm9200) support
by Anders Larsen 05 Oct '05

05 Oct '05

Hi, this patch moves the implementation of the DM9161 PHY from the board directories into cpu/arm920t/at91rm9200 (patch gzip'ed due to size) Rationale: The code in question (dm9161.c) is used by two boards, namely the at91rm9200dk and the cmc_pu2; the source file in question was present (identically) in both board-specific directories. I didn't move it into the global drivers directory, since the code is at91rm9200-specific. The patch patch also moves lxt972.c from board/kb9202 accordingly, see pending patch from 2005-04-27 "KB920x initial patch..." Changelog: * patch by Anders Larsen, 2005-04-29 move dm9161.c and lxt972.c into cpu/arm920t/at91rm9200 Cheers Anders

2 1