Re: [U-Boot] u-boot for rsk7203
Hi nobuhiro san. I'have gone ahead on my board, derived from rks7203. Now the system boots and alse the NOR flash (mine is an SST) works properly. If you like we can stay in touch for the development Best regards In data venerdì 16 luglio 2010 08:31:55, Nobuhiro Iwamatsu ha scritto: : Hi, Fabio. 2010/7/14 Fabio Giovagnini fabio.giovagn...@aurion-tech.com: Hi nobuhiro san. Is it running really on rsk7203 u-boot? in the directory board/renesas/rsk7203 the file lowlevel_init.S defines PDCRL4_A but do not ise it. So if the port are not set as Data bus, how the sysstem can boot? I dont have rsk7203 board now. It is scheduled that it is at hand next week. I will examine it next week. Best regards, Nobuhiro -- Fabio Giovagnini Aurion s.r.l. P.I e C.F. 00885711200 skype: aurion.giovagnini Tel. +39.051.594.78.24 Cell. +39.335.83.50.919 www.aurion-tech.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 4/4] edminiv2: add mvsata_ide and cmd_ide support
Pls remove below warning edminiv2.c: In function ‘board_init’: edminiv2.c:93: warning: implicit declaration of function ‘mvsata_ide_initialize_port’ Regards.. Prafulla . .. ___ From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud [albert.arib...@free.fr] Sent: Tuesday, July 13, 2010 5:32 PM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH V5 4/4] edminiv2: add mvsata_ide and cmd_ide support Add mvsata_ide port 1 initialization in edminiv2 init code Add mvsata_ide and cmd_ide configuration in edminiv2 config Signed-off-by: Albert Aribaud albert.arib...@free.fr --- board/LaCie/edminiv2/edminiv2.c |7 ++ include/configs/edminiv2.h | 46 ++- 2 files changed, 52 insertions(+), 1 deletions(-) diff --git a/board/LaCie/edminiv2/edminiv2.c b/board/LaCie/edminiv2/edminiv2.c index 54c0ffe..f0c2110 100644 --- a/board/LaCie/edminiv2/edminiv2.c +++ b/board/LaCie/edminiv2/edminiv2.c @@ -88,5 +88,12 @@ int board_init(void) /* boot parameter start at 256th byte of RAM base */ gd-bd-bi_boot_params = gd-bd-bi_dram[0].start + 0x100; +#if defined(CONFIG_MVSATA_IDE) + /* Enable SATA port 1 if SATA IDE was configured */ + mvsata_ide_initialize_port( + (struct mv_sata_port_registers *) + (ORION5X_SATA_BASE+ORION5X_SATA_PORT1_OFFSET)); +#endif + return 0; } diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index c3d95a0..0c1a8fc 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -52,6 +52,12 @@ #define CONFIG_SYS_HZ 1000 /* + * __io is necessary for cmd_ide to compile + */ + +#define __io + +/* * Board-specific values for Orion5x MPP low level init: * - MPPs 12 to 15 are SATA LEDs (mode 5) * - Others are GPIO/unused (mode 3 for MPP0, mode 5 for @@ -60,7 +66,7 @@ #define ORION5X_MPP0_7 0x0003 #define ORION5X_MPP8_150x -#define ORION5X_MPP16_23 0x +#define ORION5X_MPP16_23 0x /* * Board-specific values for Orion5x GPIO low level init: @@ -131,6 +137,7 @@ * Commands configuration - using default command set for now */ #include config_cmd_default.h + /* * Disabling some default commands for staggered bring-up */ @@ -138,6 +145,43 @@ #undef CONFIG_CMD_NET /* no net since no eth */ #undef CONFIG_CMD_NFS /* no NFS since no net */ +#define CONFIG_CMD_IDE +#define CONFIG_DOS_PARTITION +#define CONFIG_CMD_EXT2 + +/* + * ED Mini V2 has an IDE-compatible SATA connector for port 1 + */ + +#define CONFIG_MVSATA_IDE +#define CONFIG_MVSATA_IDE_USE_PORT1 + +/* Needs byte-swapping for ATA data register */ +#define CONFIG_IDE_SWAP_IO + +/* Data, registers and alternate blocks are at the same offset */ +#define CONFIG_SYS_ATA_DATA_OFFSET (0x0100) +#define CONFIG_SYS_ATA_REG_OFFSET (0x0100) +#define CONFIG_SYS_ATA_ALT_OFFSET (0x0100) + +/* Each 8-bit ATA register is aligned to a 4-bytes address */ +#define CONFIG_SYS_ATA_STRIDE 4 + +/* Controller supports 48-bits LBA addressing */ +#define CONFIG_LBA48 + +/* + * CONFIG_CMD_IDE requires some #defines for ATA registers + */ + +/* A single bus, a single device */ +#define CONFIG_SYS_IDE_MAXBUS 1 +#define CONFIG_SYS_IDE_MAXDEVICE 1 +/* ATA registers base is at SATA controller base */ +#define CONFIG_SYS_ATA_BASE_ADDR ORION5X_SATA_BASE +/* ATA bus 0 is orion5x port 1 on ED Mini V2 */ +#define CONFIG_SYS_ATA_IDE0_OFFSET ORION5X_SATA_PORT1_OFFSET + /* * Environment variables configurations */ -- 1.6.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nor Flash SST39VF6402B cfi compliant support
Hi Fabio, On Thursday 15 July 2010 11:55:17 Fabio Giovagnini wrote: In my experience the SST39VF6402B has become full compliant with CFI mtd interface just few linux kernel ago. In linux 2.6.17 it was not. I'm developing on U-Boot 2010.06-rc2-07985-g53f7677-dirty (lug 15 2010 - 11:41:21) is it compliant with SST39VF6402B Is among of you other people using on their own board such a flash? No. I haven't used those SST parts for a long time. But I assume that its still not 100% CFI compliant. But you can use the legacy infrastructure to add support to it. Shouldn't be to difficult. Take a look at: CONFIG_FLASH_CFI_LEGACY and drivers/mtd/jedec_flash.c Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-BOOT] operate on a udisk with fat32 fs, and 2048 block size will cause system to restart
I have a udisk(My MP3), which is fat32 format, and the fs block size is 4096(report by u-boot). enable USB and FAT support for u-boot. do usb start cause the system to restart. after looking into the u-boot code, I find that the DEFAULT_SECTOR_SIZE in disk/part_dos.h is too small(512) to fit a fat sector, so system run into a out of range trouble when it go into usb_storage.c/usb_stor_read() function. and I also need to change the FS_BLOCK_SIZE in include/fat.h to 4096, otherwise, the fatinfo/fatls/fatread would run into the same trouble. These is also check in u-boot-2010.06 code. The FAT doc say the number of bytes per sector will be one of 512 , 1024, 2048, 4096, so i guess that I may need to use something like malloc to alloc the sector buffer ? But it seems difficult to do. Any idea ? Thanks. /WX ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] operate on a udisk with fat32 fs, and 2048 block size will cause system to restart
sorry, typo in the title, it is 4096 On Mon, Jul 19, 2010 at 4:44 PM, wesley xie elelon...@gmail.com wrote: I have a udisk(My MP3), which is fat32 format, and the fs block size is 4096(report by u-boot). enable USB and FAT support for u-boot. do usb start cause the system to restart. after looking into the u-boot code, I find that the DEFAULT_SECTOR_SIZE in disk/part_dos.h is too small(512) to fit a fat sector, so system run into a out of range trouble when it go into usb_storage.c/usb_stor_read() function. and I also need to change the FS_BLOCK_SIZE in include/fat.h to 4096, otherwise, the fatinfo/fatls/fatread would run into the same trouble. These is also check in u-boot-2010.06 code. The FAT doc say the number of bytes per sector will be one of 512 , 1024, 2048, 4096, so i guess that I may need to use something like malloc to alloc the sector buffer ? But it seems difficult to do. Any idea ? Thanks. /WX ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Digest, Vol 26, Issue 18
Hi, I'm completely new here, but looking to ask what's the best way to send in a patch for the Xilinx SP601 board? I've got it working and tested on two separate boards, however a key point is that I don't use the microblaze-generic functionality (just the microblaze) since I found it power pc specific. Key features include: 10/100mb Emaclite Ethernet. (I tried using the gigabit Ethernet but only DMA mode rather than FIFO mode seemed close to working.) Flash support (ENV only in ram currently) Best regards, and many thanks for U-Boot! Billy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] operate on a udisk with fat32 fs, and 2048 block size will cause system to restart
or, may be we need to detect the buffer size in usb_stor_read, to prevent it from out of range ? On Mon, Jul 19, 2010 at 4:45 PM, wesley xie elelon...@gmail.com wrote: sorry, typo in the title, it is 4096 On Mon, Jul 19, 2010 at 4:44 PM, wesley xie elelon...@gmail.com wrote: I have a udisk(My MP3), which is fat32 format, and the fs block size is 4096(report by u-boot). enable USB and FAT support for u-boot. do usb start cause the system to restart. after looking into the u-boot code, I find that the DEFAULT_SECTOR_SIZE in disk/part_dos.h is too small(512) to fit a fat sector, so system run into a out of range trouble when it go into usb_storage.c/usb_stor_read() function. and I also need to change the FS_BLOCK_SIZE in include/fat.h to 4096, otherwise, the fatinfo/fatls/fatread would run into the same trouble. These is also check in u-boot-2010.06 code. The FAT doc say the number of bytes per sector will be one of 512 , 1024, 2048, 4096, so i guess that I may need to use something like malloc to alloc the sector buffer ? But it seems difficult to do. Any idea ? Thanks. /WX ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nor Flash SST39VF6402B cfi compliant support
I Stefan. I did teh following upgrade of the fileyou suggestied to me.
#define SST39VF6402B0x236c
...
#ifdef CONFIG_SYS_FLASH_LEGACY_4Mx16
{
.mfr_id = (u16)SST_MANUFACT,
.dev_id = SST39VF6402B,
.name = SST 39VF6402B,
.uaddr = {
[1] = MTD_UADDR_0x0555_0x02AA /* x16 */
},
.DevSize= SIZE_4MiB,
.CmdSet = CFI_CMDSET_AMD_LEGACY,
.NumEraseRegions= 1,
.regions= {
ERASEINFO(0x1,128),
}
},
#endif
The flash works, but not properly.
My conention is A1 mcp Bus cocceted to A0 of flash chip to have 16 bit width
for data bus. The flash datasheet tells the flash os organized in 128 32kword
of
esare sectors. So I think my setting is not correct. Is it?
Thanks a lot and best regards
In data lunedì 19 luglio 2010 09:52:23, Stefan Roese ha scritto:
: Hi Fabio,
On Thursday 15 July 2010 11:55:17 Fabio Giovagnini wrote:
In my experience the SST39VF6402B has become full compliant with CFI mtd
interface just few linux kernel ago. In linux 2.6.17 it was not.
I'm developing on
U-Boot 2010.06-rc2-07985-g53f7677-dirty (lug 15 2010 - 11:41:21)
is it compliant with SST39VF6402B
Is among of you other people using on their own board such a flash?
No. I haven't used those SST parts for a long time. But I assume that its
still not 100% CFI compliant. But you can use the legacy infrastructure to
add support to it. Shouldn't be to difficult. Take a look at:
CONFIG_FLASH_CFI_LEGACY
and
drivers/mtd/jedec_flash.c
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
--
Fabio Giovagnini
Aurion s.r.l.
P.I e C.F.
00885711200
skype: aurion.giovagnini
Tel. +39.051.594.78.24
Cell. +39.335.83.50.919
www.aurion-tech.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nor Flash SST39VF6402B cfi compliant support
On Monday 19 July 2010 11:04:34 Fabio Giovagnini wrote:
I Stefan. I did teh following upgrade of the fileyou suggestied to me.
#define SST39VF6402B 0x236c
...
#ifdef CONFIG_SYS_FLASH_LEGACY_4Mx16
{
.mfr_id = (u16)SST_MANUFACT,
.dev_id = SST39VF6402B,
.name = SST 39VF6402B,
.uaddr = {
[1] = MTD_UADDR_0x0555_0x02AA /* x16 */
},
.DevSize= SIZE_4MiB,
.CmdSet = CFI_CMDSET_AMD_LEGACY,
.NumEraseRegions= 1,
.regions= {
ERASEINFO(0x1,128),
}
},
#endif
The flash works, but not properly.
What's exactly not working?
My conention is A1 mcp Bus cocceted to A0 of flash chip to have 16 bit
width for data bus. The flash datasheet tells the flash os organized in
128 32kword of esare sectors. So I think my setting is not correct. Is it?
Could be. IIRC, then the SST parts have 2 different erase regions, the
normal ones and the smaller ones (4k???). Not sure which one is used by this
command set. I suggest you investigate here further.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nor Flash SST39VF6402B cfi compliant support
Hi Fabio, (please keep the list on Cc). On Monday 19 July 2010 11:27:50 Fabio Giovagnini wrote: I do not think so about teh different regons. I attach the datasheet I found on the net and I cannot find anythink about two different regions for SST39VF6402B Maybe I'm wrong. Yes, you are wrong. ;) The manual mentions block-erase (32k) and sector-erase (2k). Please check which one is used by the CFi commands right now. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non standard CFI detection tweaks
Hi Rogan, On Tuesday 13 July 2010 22:00:37 Rogan Dawes wrote: I'm trying to add support for my D-Link DNS323 (Orion5x-based) to U-Boot, building on the efforts of Albert Aribaud. One place where I am struggling is with the detection of the flash chip. The flash part is a 8 MB Spansion S29GL064M90TFIR4, and the data sheet can be found at: http://www.spansion.com/Support/Datasheets/s29gl-m_00_b8_e.pdf It says: This device enters the CFI Query mode when the system writes the CFI Query command, 98h, to address 55h, any time the device is ready to read array data. Testing this from the command line, however, shows that this is in fact NOT true. In fact, the write needs to occur at aah, not 55h. This is most likely because of the 8bit width (byte address) vs. 16bit width (word address) modes. How is your FLASH chip connected to your CPU? In 16bit wide mode (which is more common)? This may be influenced by the following paragraph from the manual: Depending on the model number, the devices have an 8-bit wide data bus only, 16-bit wide data bus only, or a 16-bit wide data bus that can also function as an 8-bit wide data bus by using the BYTE# input. And: R4 = x8/x16 Looking at the debug logs from cfi_flash.c, I see the following output: fwc addr ff8000aa cmd 98 9898 16bit x 8 bit is= cmd 51(Q) addr ff800020 is= 5151 These lines are the closest to doing what appears to be needed for this part, in that the address being written to is correct, the address being read from is correct, the expected result is correct. The only thing that is not correct is the command to enter QRY mode. For this particular chip, the command is: mw.w 0xff8000aa 9800 (rather than 9898) (FWIW mw.b 0xff8000aa 98 also works fine to enter QRY mode) Hmmm. Again my question: Are you using byte- or word-mode? Having done that, the QRY results are present at 0xff800020: md.b ff800020 20 ff800020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 QQRRYY@@ ff800030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 04 04 ..''66.. Do you have any suggestions on the best way to modify cfi_flash.c to detect this chip? Not right now, sorry. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] FAT32: Superfloppy format and other fixes
Superfloppy format (in U-Boot called PBR) did not work for FAT32 due to several errors; some errors appaeared only in certain configurations (like directories with more than 128 entries, etc.). These patches are supposed to fix these issues. Wolfgang Denk (5): usb_storage.c: initialize device type FAT32: fix support for superfloppy-format (PBR) FAT32: fix broken root directory handling. usb_storage.c: change progress output in debug() message fs/fat: Big code cleanup. common/cmd_fat.c | 210 ++ common/usb_storage.c |9 +- disk/part_dos.c |4 +- disk/part_dos.h |3 +- fs/fat/fat.c | 1143 -- fs/fat/file.c| 14 +- include/fat.h| 63 ++-- 7 files changed, 717 insertions(+), 729 deletions(-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Misquotation is, in fact, the pride and privilege of the learned. A widely-read man never quotes accurately, for the rather obvious reason that he has read too widely. - Hesketh Pearson _Common Misquotations_ introduction ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] usb_storage.c: initialize device type
The device type was left uninitialized which caused later tests
against DEV_TYPE_UNKNOWN to fail. In the result, usb part would
attempt to print information about non-existent devices like this:
= usb part
print_part of 0
Partition Map for USB device 0 -- Partition Type: DOS
Partition Start Sector Num Sectors Type
10 2031616 f8
print_part of 1
## Unknown partition table
print_part of 2
## Unknown partition table
print_part of 3
## Unknown partition table
print_part of 4
## Unknown partition table
=
By initializing the type as DEV_TYPE_UNKNOWN we avoid all the
Unknown partition table messages.
[Note: the print_part of ? messages is left over debug code that
will be removed in another patch.]
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Remy Bohmer li...@bohmer.net
---
common/usb_storage.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index 4fc01a2..9f31265 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -224,10 +224,11 @@ int usb_stor_scan(int mode)
for (i = 0; i USB_MAX_STOR_DEV; i++) {
memset(usb_dev_desc[i], 0, sizeof(block_dev_desc_t));
- usb_dev_desc[i].target = 0xff;
usb_dev_desc[i].if_type = IF_TYPE_USB;
usb_dev_desc[i].dev = i;
usb_dev_desc[i].part_type = PART_TYPE_UNKNOWN;
+ usb_dev_desc[i].target = 0xff;
+ usb_dev_desc[i].type = DEV_TYPE_UNKNOWN;
usb_dev_desc[i].block_read = usb_stor_read;
usb_dev_desc[i].block_write = usb_stor_write;
}
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] FAT32: fix support for superfloppy-format (PBR)
Superfloppy format (in U-Boot called PBR) did not work for FAT32 as
the file system type string is at a different location. Add support
for FAT32.
Signed-off-by: Wolfgang Denk w...@denx.de
---
disk/part_dos.c |4 +++-
disk/part_dos.h |3 ++-
fs/fat/fat.c|4 +++-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 887b75e..2de1bb8 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -77,8 +77,10 @@ static int test_block_type(unsigned char *buffer)
(buffer[DOS_PART_MAGIC_OFFSET + 1] != 0xaa) ) {
return (-1);
} /* no DOS Signature at all */
- if(strncmp((char *)buffer[DOS_PBR_FSTYPE_OFFSET],FAT,3)==0)
+ if (strncmp((char *)buffer[DOS_PBR_FSTYPE_OFFSET],FAT,3)==0 ||
+ strncmp((char *)buffer[DOS_PBR32_FSTYPE_OFFSET],FAT32,5)==0) {
return DOS_PBR; /* is PBR */
+ }
return DOS_MBR; /* Is MBR */
}
diff --git a/disk/part_dos.h b/disk/part_dos.h
index ac93f20..195a32c 100644
--- a/disk/part_dos.h
+++ b/disk/part_dos.h
@@ -28,13 +28,14 @@
#ifdef CONFIG_ISO_PARTITION
/* Make the buffers bigger if ISO partition support is enabled -- CD-ROMS
have 2048 byte blocks */
-#define DEFAULT_SECTOR_SIZE 2048
+#define DEFAULT_SECTOR_SIZE2048
#else
#define DEFAULT_SECTOR_SIZE512
#endif
#define DOS_PART_TBL_OFFSET0x1be
#define DOS_PART_MAGIC_OFFSET 0x1fe
#define DOS_PBR_FSTYPE_OFFSET 0x36
+#define DOS_PBR32_FSTYPE_OFFSET0x52
#define DOS_PBR_MEDIA_TYPE_OFFSET 0x15
#define DOS_MBR0
#define DOS_PBR1
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 6b3a274..0b2febe 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -50,6 +50,7 @@ static int cur_part = 1;
#define DOS_PART_TBL_OFFSET0x1be
#define DOS_PART_MAGIC_OFFSET 0x1fe
#define DOS_FS_TYPE_OFFSET 0x36
+#define DOS_FS32_TYPE_OFFSET 0x52
int disk_read (__u32 startblock, __u32 getsize, __u8 * bufptr)
{
@@ -94,7 +95,8 @@ fat_register_device(block_dev_desc_t *dev_desc, int part_no)
if (!get_partition_info (dev_desc, part_no, info)) {
part_offset = info.start;
cur_part = part_no;
- } else if (!strncmp((char *)buffer[DOS_FS_TYPE_OFFSET], FAT, 3)) {
+ } else if (strncmp((char *)buffer[DOS_FS_TYPE_OFFSET], FAT, 3)==0 ||
+ strncmp((char *)buffer[DOS_FS32_TYPE_OFFSET],FAT32,5)==0)
{
/* ok, we assume we are on a PBR only */
cur_part = 1;
part_offset = 0;
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] usb_storage.c: change progress output in debug() message
The dots printed by common/usb_storage.c as progress meter corrupt the
output for example of fatls usb commands like this:
= fatls usb 0
. here
29 file.001
29 file.002
29 file.003
29 file.004
29 file.005
29 file.006
29 file.007
29 file.008
29 file.009
29 file.010
29 file.011
29 file.012
29 file.013
29 file.014
29 file.015
29 file.016
. here
29 file.017
29 file.018
29 file.019
...
Turn the progress output into a debug message.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Remy Bohmer li...@bohmer.net
---
common/usb_storage.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index 9f31265..76949b8 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -181,7 +181,7 @@ block_dev_desc_t *usb_stor_get_dev(int index)
void usb_show_progress(void)
{
- printf(.);
+ debug(.);
}
/***
@@ -1081,7 +1081,7 @@ retry_it:
usb_disable_asynch(0); /* asynch transfer allowed */
if (blkcnt = USB_MAX_READ_BLK)
- printf(\n);
+ debug(\n);
return blkcnt;
}
@@ -1161,7 +1161,7 @@ retry_it:
usb_disable_asynch(0); /* asynch transfer allowed */
if (blkcnt = USB_MAX_WRITE_BLK)
- printf(\n);
+ debug(\n);
return blkcnt;
}
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] FAT32: fix broken root directory handling.
On FAT32, instead of fetching the cluster numbers from the FAT, the
code assumed (incorrectly) that the clusters for the root directory
were allocated contiguously. In the result, only the first cluster
could be accessed. At the typical cluster size of 8 sectors this
caused all accesses to files after the first 128 entries to fail -
fatls would terminate after 128 files (usually displaying a bogus
file name, occasionally even crashing the system), and fatload
would fail to find any files that were not in the first directory
cluster.
Signed-off-by: Wolfgang Denk w...@denx.de
---
fs/fat/fat.c | 60 -
1 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 0b2febe..413c687 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -200,6 +200,9 @@ get_fatent(fsdata *mydata, __u32 entry)
return ret;
}
+ FAT_DPRINT(FAT%d: entry: 0x%04x = %d, offset: 0x%04x = %d\n,
+ mydata-fatsize, entry, entry, offset, offset);
+
/* Read a new block of FAT entries into the cache. */
if (bufnum != mydata-fatbufnum) {
int getsize = FATBUFSIZE/FS_BLOCK_SIZE;
@@ -259,7 +262,8 @@ get_fatent(fsdata *mydata, __u32 entry)
}
break;
}
- FAT_DPRINT(ret: %d, offset: %d\n, ret, offset);
+ FAT_DPRINT(FAT%d: ret: %08x, offset: %04x\n,
+ mydata-fatsize, ret, offset);
return ret;
}
@@ -322,7 +326,7 @@ get_contents(fsdata *mydata, dir_entry *dentptr, __u8
*buffer,
if (maxsize 0 filesize maxsize) filesize = maxsize;
- FAT_DPRINT(Reading: %ld bytes\n, filesize);
+ FAT_DPRINT(%ld bytes\n, filesize);
actsize=bytesperclust;
endclust=curclust;
@@ -718,16 +722,19 @@ do_fat_read (const char *filename, void *buffer, unsigned
long maxsize,
dir_entry *dentptr;
__u16 prevcksum = 0x;
char *subname = ;
-int rootdir_size, cursect;
+int cursect;
int idx, isdir = 0;
int files = 0, dirs = 0;
long ret = 0;
int firsttime;
+int root_cluster;
+int j;
if (read_bootsectandvi (bs, volinfo, mydata-fatsize)) {
FAT_DPRINT (Error: reading boot sector\n);
return -1;
}
+ root_cluster = bs.root_cluster;
if (mydata-fatsize == 32) {
mydata-fatlength = bs.fat32_length;
} else {
@@ -738,10 +745,11 @@ do_fat_read (const char *filename, void *buffer, unsigned
long maxsize,
= mydata-fat_sect + mydata-fatlength * bs.fats;
mydata-clust_size = bs.cluster_size;
if (mydata-fatsize == 32) {
- rootdir_size = mydata-clust_size;
- mydata-data_begin = mydata-rootdir_sect /* + rootdir_size */
+ mydata-data_begin = mydata-rootdir_sect
- (mydata-clust_size * 2);
} else {
+ int rootdir_size;
+
rootdir_size = ((bs.dir_entries[1] * (int) 256 + bs.dir_entries[0])
* sizeof (dir_entry)) / SECTOR_SIZE;
mydata-data_begin = mydata-rootdir_sect + rootdir_size
@@ -749,12 +757,19 @@ do_fat_read (const char *filename, void *buffer, unsigned
long maxsize,
}
mydata-fatbufnum = -1;
-FAT_DPRINT (FAT%d, fatlength: %d\n, mydata-fatsize,
+#ifdef CONFIG_SUPPORT_VFAT
+FAT_DPRINT (VFAT Support enabled\n);
+#endif
+FAT_DPRINT (FAT%d, fat_sect: %d, fatlength: %d\n,
+ mydata-fatsize,
+ mydata-fat_sect,
mydata-fatlength);
-FAT_DPRINT (Rootdir begins at sector: %d, offset: %x, size: %d\n
+FAT_DPRINT (Rootdir begins at cluster: %d, sector: %d, offset: %x\n
Data begins at: %d\n,
- mydata-rootdir_sect, mydata-rootdir_sect * SECTOR_SIZE,
- rootdir_size, mydata-data_begin);
+ root_cluster,
+ mydata-rootdir_sect,
+ mydata-rootdir_sect * SECTOR_SIZE,
+ mydata-data_begin);
FAT_DPRINT (Cluster size: %d\n, mydata-clust_size);
/* cwd is always the root... */
@@ -778,9 +793,12 @@ do_fat_read (const char *filename, void *buffer, unsigned
long maxsize,
isdir = 1;
}
+j=0;
while (1) {
int i;
+ FAT_DPRINT (FAT read sect=%d, clust_size=%d, DIRENTSPERBLOCK=%d\n,
+ cursect, mydata-clust_size, DIRENTSPERBLOCK);
if (disk_read (cursect, mydata-clust_size, do_fat_read_block) 0) {
FAT_DPRINT (Error: reading rootdir block\n);
return -1;
@@ -893,7 +911,29 @@ do_fat_read (const char *filename, void *buffer, unsigned
long maxsize,
goto rootdir_done; /* We got a match */
}
- cursect++;
+ FAT_DPRINT (END LOOP: j=%d clust_size=%d\n, j, mydata-clust_size);
+
+ /*
+* On FAT32 we must fetch the FAT entries for the next
+* root directory clusters when a cluster has been
+* completely processed.
+*/
+ if ((mydata-fatsize
[U-Boot] [PATCH 5/5] fs/fat: Big code cleanup.
- reformat
- throw out macros like FAT_DPRINT and FAT_DPRINT
- remove dead code
Signed-off-by: Wolfgang Denk w...@denx.de
---
common/cmd_fat.c | 210 ++
fs/fat/fat.c | 1167 +-
fs/fat/file.c| 14 +-
include/fat.h| 63 ++--
4 files changed, 698 insertions(+), 756 deletions(-)
diff --git a/common/cmd_fat.c b/common/cmd_fat.c
index ede7308..0220494 100644
--- a/common/cmd_fat.c
+++ b/common/cmd_fat.c
@@ -45,39 +45,43 @@ int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
char *ep;
if (argc 5) {
- printf (usage: fatload interface dev[:part] addr
filename [bytes]\n);
+ printf( usage: fatload interface dev[:part]
+ addr filename [bytes]\n);
return 1;
}
- dev = (int)simple_strtoul (argv[2], ep, 16);
- dev_desc=get_dev(argv[1],dev);
- if (dev_desc==NULL) {
- puts (\n** Invalid boot device **\n);
+
+ dev = (int)simple_strtoul(argv[2], ep, 16);
+ dev_desc = get_dev(argv[1],dev);
+ if (dev_desc == NULL) {
+ puts(\n** Invalid boot device **\n);
return 1;
}
if (*ep) {
if (*ep != ':') {
- puts (\n** Invalid boot device, use `dev[:part]'
**\n);
+ puts(\n** Invalid boot device, use `dev[:part]' **\n);
return 1;
}
part = (int)simple_strtoul(++ep, NULL, 16);
}
if (fat_register_device(dev_desc,part)!=0) {
- printf (\n** Unable to use %s %d:%d for fatload
**\n,argv[1],dev,part);
+ printf(\n** Unable to use %s %d:%d for fatload **\n,
+ argv[1], dev, part);
return 1;
}
- offset = simple_strtoul (argv[3], NULL, 16);
+ offset = simple_strtoul(argv[3], NULL, 16);
if (argc == 6)
- count = simple_strtoul (argv[5], NULL, 16);
+ count = simple_strtoul(argv[5], NULL, 16);
else
count = 0;
- size = file_fat_read (argv[4], (unsigned char *) offset, count);
+ size = file_fat_read(argv[4], (unsigned char *)offset, count);
if(size==-1) {
- printf(\n** Unable to read \%s\ from %s %d:%d
**\n,argv[4],argv[1],dev,part);
+ printf(\n** Unable to read \%s\ from %s %d:%d **\n,
+ argv[4], argv[1], dev, part);
return 1;
}
- printf (\n%ld bytes read\n, size);
+ printf(\n%ld bytes read\n, size);
sprintf(buf, %lX, size);
setenv(filesize, buf);
@@ -104,34 +108,35 @@ int do_fat_ls (cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
block_dev_desc_t *dev_desc=NULL;
if (argc 3) {
- printf (usage: fatls interface dev[:part] [directory]\n);
- return (0);
+ printf(usage: fatls interface dev[:part] [directory]\n);
+ return 0;
}
- dev = (int)simple_strtoul (argv[2], ep, 16);
- dev_desc=get_dev(argv[1],dev);
- if (dev_desc==NULL) {
- puts (\n** Invalid boot device **\n);
+ dev = (int)simple_strtoul(argv[2], ep, 16);
+ dev_desc = get_dev(argv[1],dev);
+ if (dev_desc == NULL) {
+ puts(\n** Invalid boot device **\n);
return 1;
}
if (*ep) {
if (*ep != ':') {
- puts (\n** Invalid boot device, use `dev[:part]'
**\n);
+ puts(\n** Invalid boot device, use `dev[:part]' **\n);
return 1;
}
part = (int)simple_strtoul(++ep, NULL, 16);
}
if (fat_register_device(dev_desc,part)!=0) {
- printf (\n** Unable to use %s %d:%d for fatls
**\n,argv[1],dev,part);
+ printf(\n** Unable to use %s %d:%d for fatls **\n,
+ argv[1], dev, part);
return 1;
}
if (argc == 4)
- ret = file_fat_ls (argv[3]);
+ ret = file_fat_ls(argv[3]);
else
- ret = file_fat_ls (filename);
+ ret = file_fat_ls(filename);
if(ret!=0)
printf(No Fat FS detected\n);
- return (ret);
+ return ret;
}
U_BOOT_CMD(
@@ -149,27 +154,28 @@ int do_fat_fsinfo (cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
block_dev_desc_t *dev_desc=NULL;
if (argc 2) {
- printf (usage: fatinfo interface dev[:part]\n);
- return (0);
+ printf(usage: fatinfo interface dev[:part]\n);
+ return 0;
}
- dev = (int)simple_strtoul (argv[2], ep, 16);
- dev_desc=get_dev(argv[1],dev);
- if (dev_desc==NULL) {
- puts (\n** Invalid boot device
Re: [U-Boot] guys, can you see some init code for davinci's chipselect bit width driving DM9000A?
yaojin liu wrote: hi: dm9000a works as 16bit bus width. however, i have not seen any init code for the dm355's chipselect. and by default ,the cs1 is 8bit bus width at reset. how doew it work? I think the setup is done by the UBL provided by TI. U-boot is a 3-rd stage bootloader for DM355. The RBL (Rom Bootloader) loads the UBL from storage, that sets up the required peripherals (RAM / AEMIF), and then loads u-boot. u-boot does not set the a2cr register in the AEMIF interface, but the UBL has already configured it for 16-bit access. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non standard CFI detection tweaks
On 2010/07/19 11:34 AM, Stefan Roese wrote: Hi Rogan, Hi Stefan, Thanks for responding. On Tuesday 13 July 2010 22:00:37 Rogan Dawes wrote: I'm trying to add support for my D-Link DNS323 (Orion5x-based) to U-Boot, building on the efforts of Albert Aribaud. One place where I am struggling is with the detection of the flash chip. The flash part is a 8 MB Spansion S29GL064M90TFIR4, and the data sheet can be found at: http://www.spansion.com/Support/Datasheets/s29gl-m_00_b8_e.pdf It says: This device enters the CFI Query mode when the system writes the CFI Query command, 98h, to address 55h, any time the device is ready to read array data. Testing this from the command line, however, shows that this is in fact NOT true. In fact, the write needs to occur at aah, not 55h. This is most likely because of the 8bit width (byte address) vs. 16bit width (word address) modes. How is your FLASH chip connected to your CPU? In 16bit wide mode (which is more common)? I have no idea. Do you have any suggestions how I can find out? If I do a normal md over the rest of the flash, I do see expected strings from the U-Boot partition, and the kernel and ramdisk partitions. i.e. not duplicated or anything like that. Not sure if that answers your question at all? [snip] Do you have any suggestions on the best way to modify cfi_flash.c to detect this chip? Not right now, sorry. Cheers, Stefan Any hints on how to get more information to assist in debugging this? The CPU is an Orion5x (ARM) part, if that makes any difference. Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nor Flash SST39VF6402B cfi compliant support
I supposed the list doesn't like the attachment. Anyway I understand, now. I'll make you know how I'll solve. Thanks a lot and best regards In data lunedì 19 luglio 2010 11:33:43, Stefan Roese ha scritto: : Hi Fabio, (please keep the list on Cc). On Monday 19 July 2010 11:27:50 Fabio Giovagnini wrote: I do not think so about teh different regons. I attach the datasheet I found on the net and I cannot find anythink about two different regions for SST39VF6402B Maybe I'm wrong. Yes, you are wrong. ;) The manual mentions block-erase (32k) and sector-erase (2k). Please check which one is used by the CFi commands right now. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de -- Fabio Giovagnini Aurion s.r.l. P.I e C.F. 00885711200 skype: aurion.giovagnini Tel. +39.051.594.78.24 Cell. +39.335.83.50.919 www.aurion-tech.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non standard CFI detection tweaks
Hi Rogan, On Monday 19 July 2010 12:18:45 Rogan Dawes wrote: How is your FLASH chip connected to your CPU? In 16bit wide mode (which is more common)? I have no idea. Do you have any suggestions how I can find out? I don't suppose you have the schematics for this board? If I do a normal md over the rest of the flash, I do see expected strings from the U-Boot partition, and the kernel and ramdisk partitions. i.e. not duplicated or anything like that. Not sure if that answers your question at all? No, it doesn't. But the unlocking addresses should give us the result (8bit vs. 16bit wide connection). What does work for you? The byte addresses or the word addresses (read manufacturer ID)? Byte addresses: = mw.b base + aaa aa = mw.b base + 555 55 = mw.b base + aaa 90 = md.b base Word addresses: = mw.w base + 555 00aa = mw.w base + 2aa 0055 = mw.w base + 555 0090 = md.w base What's the output of those commands? Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non standard CFI detection tweaks
On 2010/07/19 12:49 PM, Stefan Roese wrote: Hi Rogan, On Monday 19 July 2010 12:18:45 Rogan Dawes wrote: How is your FLASH chip connected to your CPU? In 16bit wide mode (which is more common)? I have no idea. Do you have any suggestions how I can find out? I don't suppose you have the schematics for this board? No, I'm afraid not. If I do a normal md over the rest of the flash, I do see expected strings from the U-Boot partition, and the kernel and ramdisk partitions. i.e. not duplicated or anything like that. Not sure if that answers your question at all? No, it doesn't. But the unlocking addresses should give us the result (8bit vs. 16bit wide connection). What does work for you? The byte addresses or the word addresses (read manufacturer ID)? Byte addresses: = mw.b base + aaa aa = mw.b base + 555 55 = mw.b base + aaa 90 = md.b base DNS323B1 mw.b 0xff800aaa aa DNS323B1 mw.b 0xff800555 55 DNS323B1 mw.b 0xff800aaa 90 DNS323B1 md.b 0xff80 ff80: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08 ff800010: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08 ff800020: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08 ff800030: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08 DNS323B1 mw.b ff80 f0 DNS323B1 mw.b ff80 ff DNS323B1 md.b 0xff80 ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff800010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff800020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff800030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Word addresses: = mw.w base + 555 00aa = mw.w base + 2aa 0055 = mw.w base + 555 0090 = md.w base This is quite odd, though. DNS323B1 mw.w 0xff800555 00aa ... never returns. It seems to hang up the board for some reason. What's the output of those commands? Cheers, Stefan Thanks for your help! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-V2 1/3] at91: Defined main clock frequency on esd at91 boards
Hi Daniel, -Original Message- From: Daniel Gorsulowski [mailto:daniel.gorsulow...@esd.eu] Sent: 2010?7?16? 14:22 To: u-boot@lists.denx.de Cc: Xu, Hong; Daniel Gorsulowski Subject: [PATCH-V2 1/3] at91: Defined main clock frequency on esd at91 boards Autodetection is undesired now Signed-off-by: Daniel Gorsulowski daniel.gorsulow...@esd.eu Acked-By: Hong Xu hong...@atmel.com --- v2: fixed copyright changing error according to Wolfgangs hint include/configs/meesc.h |3 ++- include/configs/otc570.h |1 + 2 files changed, 3 insertions(+), 1 deletions(-) BR, Eric [...] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-V2 3/3] at91: Enabeling USB host on meesc board
Hi Daniel, -Original Message- From: Daniel Gorsulowski [mailto:daniel.gorsulow...@esd.eu] Sent: 2010?7?16? 14:23 To: u-boot@lists.denx.de Cc: Xu, Hong; Daniel Gorsulowski Subject: [PATCH-V2 3/3] at91: Enabeling USB host on meesc board There was an redesign, so USB is available now. Signed-off-by: Daniel Gorsulowski daniel.gorsulow...@esd.eu Acked-By: Hong Xu hong...@atmel.com --- v2: Nothing changed but commit message Note: This patch depends on 'at91: Update meesc board to new SoC access' patch! board/esd/meesc/meesc.c |6 +- include/configs/meesc.h | 13 - 2 files changed, 17 insertions(+), 2 deletions(-) BR, Eric [...] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-V2 2/3] at91: Update meesc board to new SoC access
Hi Daniel, -Original Message- From: Daniel Gorsulowski [mailto:daniel.gorsulow...@esd.eu] Sent: 2010?7?16? 14:23 To: u-boot@lists.denx.de Cc: Xu, Hong; Daniel Gorsulowski Subject: [PATCH-V2 2/3] at91: Update meesc board to new SoC access * convert meesc board to use c stucture SoC access * change gpio access to at91_gpio syntax * moved CONFIG_SYS_HZ below board and cpu defines (purely cosmetic) Signed-off-by: Daniel Gorsulowski daniel.gorsulow...@esd.eu --- I checked this patch with linux-2.6.34/scripts/checkpatch.pl and this script reports some indent(tab/space) problems. Could you please fix them. Acked-By: Hong Xu hong...@atmel.com v2: fixed copyright changing error according to Wolfgangs hint board/esd/meesc/meesc.c | 112 -- include/configs/meesc.h |9 ++-- 2 files changed, 62 insertions(+), 59 deletions(-) BR, Eric [...] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non standard CFI detection tweaks
On Monday 19 July 2010 13:05:09 Rogan Dawes wrote: If I do a normal md over the rest of the flash, I do see expected strings from the U-Boot partition, and the kernel and ramdisk partitions. i.e. not duplicated or anything like that. Not sure if that answers your question at all? No, it doesn't. But the unlocking addresses should give us the result (8bit vs. 16bit wide connection). What does work for you? The byte addresses or the word addresses (read manufacturer ID)? Byte addresses: = mw.b base + aaa aa = mw.b base + 555 55 = mw.b base + aaa 90 = md.b base DNS323B1 mw.b 0xff800aaa aa DNS323B1 mw.b 0xff800555 55 DNS323B1 mw.b 0xff800aaa 90 DNS323B1 md.b 0xff80 ff80: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08 ... ff800010: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08 ... ff800020: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08 ... ff800030: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08 ... This doesn't seem to be the manufacturer/device ID. Not sure what it really is. DNS323B1 mw.b ff80 f0 DNS323B1 mw.b ff80 ff DNS323B1 md.b 0xff80 ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... ff800010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... ff800020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... ff800030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... Word addresses: = mw.w base + 555 00aa = mw.w base + 2aa 0055 = mw.w base + 555 0090 = md.w base This is quite odd, though. DNS323B1 mw.w 0xff800555 00aa .. never returns. It seems to hang up the board for some reason. Ahh, unaligned 16bit access on ARM. Please give these commands another try: = mw.w ff800aaa 00aa = mw.w ff800554 0055 = mw.w ff800aaa 0090 = md.w ff80 Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4 v2] AM35X: Add musb support
Remy, Any comment on this patch set ? Regards, Ajay He sent me an e-mail offline. He is on vacation without Wifi and laptop. Thanks for updating on this. Regards, Ajay Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v2] 8xx, kup4: minor configuration changes
- nfs-options removed
- hda-sda changed
- mtd parts added
- loadaddress changed
- cmd-line length increased
- lcd stuff removed
- code cleanup
Signed-off-by: Klaus Heydeck heyd...@kieback-peter.de
---
- changes since v1:
- added comments from Wolfgang Denk
- fix Codingstyle issues
- rebased against current mainline
board/kup/common/kup.c | 54 --
board/kup/common/kup.h | 44 +++--
board/kup/kup4k/kup4k.c| 439 +---
board/kup/kup4k/s1d13706.h | 174 -
board/kup/kup4x/kup4x.c| 265 ---
include/configs/KUP4K.h| 169 ++
include/configs/KUP4X.h| 64
7 files changed, 426 insertions(+), 783 deletions(-)
delete mode 100644 board/kup/kup4k/s1d13706.h
diff --git a/board/kup/common/kup.c b/board/kup/common/kup.c
index 2418d59..38259a5 100644
--- a/board/kup/common/kup.c
+++ b/board/kup/common/kup.c
@@ -24,49 +24,61 @@
#include common.h
#include mpc8xx.h
#include kup.h
+#include asm/io.h
-int misc_init_f (void)
+
+int misc_init_f(void)
{
volatile immap_t *immap = (immap_t *) CONFIG_SYS_IMMR;
volatile sysconf8xx_t *siu = immap-im_siu_conf;
- while (siu-sc_sipend 0x2000) {
- /* printf(waiting for 5V VCC\n); */
- ;
+ while (in_be32(siu-sc_sipend) 0x2000) {
+ debug(waiting for 5V VCC\n);
}
/* RS232 / RS485 default is RS232 */
- immap-im_ioport.iop_padat = ~(PA_RS485);
- immap-im_ioport.iop_papar = ~(PA_RS485);
- immap-im_ioport.iop_paodr = ~(PA_RS485);
- immap-im_ioport.iop_padir |= (PA_RS485);
+ clrbits_be16(immap-im_ioport.iop_padat, PA_RS485);
+ clrbits_be16(immap-im_ioport.iop_papar, PA_RS485);
+ clrbits_be16(immap-im_ioport.iop_paodr, PA_RS485);
+ setbits_be16(immap-im_ioport.iop_padir, PA_RS485);
+
+ /* IO Reset min 1 msec */
+ setbits_be16(immap-im_ioport.iop_padat,
+(PA_RESET_IO_01 | PA_RESET_IO_02));
+ clrbits_be16(immap-im_ioport.iop_papar,
+(PA_RESET_IO_01 | PA_RESET_IO_02));
+ clrbits_be16(immap-im_ioport.iop_paodr,
+(PA_RESET_IO_01 | PA_RESET_IO_02));
+ setbits_be16(immap-im_ioport.iop_padir,
+(PA_RESET_IO_01 | PA_RESET_IO_02));
+ udelay(1000);
+ clrbits_be16(immap-im_ioport.iop_padat,
+(PA_RESET_IO_01 | PA_RESET_IO_02));
return (0);
}
-
#ifdef CONFIG_IDE_LED
-void ide_led (uchar led, uchar status)
+void ide_led(uchar led, uchar status)
{
volatile immap_t *immap = (immap_t *) CONFIG_SYS_IMMR;
/* We have one led for both pcmcia slots */
- if (status) { /* led on */
- immap-im_ioport.iop_padat = ~(PA_LED_YELLOW);
- } else {
- immap-im_ioport.iop_padat |= (PA_LED_YELLOW);
- }
+ if (status)
+ clrbits_be16(immap-im_ioport.iop_padat, PA_LED_YELLOW);
+ else
+ setbits_be16(immap-im_ioport.iop_padat, PA_LED_YELLOW);
}
#endif
-void poweron_key (void)
+void poweron_key(void)
{
volatile immap_t *immap = (immap_t *) CONFIG_SYS_IMMR;
- immap-im_ioport.iop_pcpar = ~(PC_SWITCH1);
- immap-im_ioport.iop_pcdir = ~(PC_SWITCH1);
+ clrbits_be16(immap-im_ioport.iop_pcpar, PC_SWITCH1);
+ clrbits_be16(immap-im_ioport.iop_pcdir, PC_SWITCH1);
- if (immap-im_ioport.iop_pcdat (PC_SWITCH1))
- setenv (key1, off);
+ if (in_be16(immap-im_ioport.iop_pcdat) (PC_SWITCH1))
+ setenv(key1, off);
else
- setenv (key1, on);
+ setenv(key1, on);
}
diff --git a/board/kup/common/kup.h b/board/kup/common/kup.h
index b736283..455848c 100644
--- a/board/kup/common/kup.h
+++ b/board/kup/common/kup.h
@@ -24,23 +24,33 @@
#ifndef __KUP_H
#define __KUP_H
-#define PA_8 0x0080
-#define PA_11 0x0010
-#define PA_12 0x0008
-
-#define PB_14 0x0002
-#define PB_17 0x4000
-
-#define PC_9 0x0040
-
-#define PA_RS485 PA_11 /* SCC1: 0=RS232 1=RS485 */
-#define PA_LED_YELLOWPA_8
-#define BP_USB_VCC PB_14 /* VCC for USB devices 0=vcc on,
1=vcc off*/
-#define PB_LCD_PWM PB_17 /* PB 17 */
-#define PC_SWITCH1 PC_9/* Reboot switch */
-
-extern void poweron_key (void);
-
+#define PA_8 0x0080
+#define PA_9 0x0040
+#define PA_10 0x0020
+#define PA_11 0x0010
+#define PA_12 0x0008
+
+#define PB_14 0x0002
+#define PB_15 0x0001
+#define PB_16 0x8000
+#define PB_17 0x4000
+
+#define PC_4 0x0800
+#define PC_5 0x0400
+#define PC_9 0x0040
+
+#define PA_RS485 PA_11 /* SCC1: 0=RS232 1=RS485 */
+#define PA_LED_YELLOW PA_8
+#define PA_RESET_IO_01 PA_9/* Reset left IO */
+#define PA_RESET_IO_02
[U-Boot] [PATCH] net, fec: fix Warning: eth device name has a space! for FEC devices
since commit 1384f3bb8a4f9066805b70c1418eda78ecb73fdd ethernet names
with spaces drop a
Warning: eth device name has a space!
message. This patch fix it for FEC ETHERNET devices found on
mpc512x, mpc5xxx, mpc8xx and mpc8220 boards.
Tested on the kup4k board.
Signed-off-by: Heiko Schocher h...@denx.de
---
arch/powerpc/cpu/mpc8220/fec.c |2 +-
arch/powerpc/cpu/mpc8xx/fec.c |4 ++--
board/motionpro/motionpro.c|4 ++--
board/stx/stxxtc/stxxtc.c |6 +++---
board/tqc/tqm8xx/tqm8xx.c |4 ++--
drivers/net/mpc512x_fec.c |2 +-
drivers/net/mpc5xxx_fec.c |2 +-
include/configs/NSCU.h |1 -
include/configs/TK885D.h |6 +++---
include/configs/idmr.h |2 +-
include/configs/v38b.h |2 +-
11 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8220/fec.c b/arch/powerpc/cpu/mpc8220/fec.c
index 5df9735..cf0ce4a 100644
--- a/arch/powerpc/cpu/mpc8220/fec.c
+++ b/arch/powerpc/cpu/mpc8220/fec.c
@@ -840,7 +840,7 @@ int mpc8220_fec_initialize (bd_t * bis)
dev-send = mpc8220_fec_send;
dev-recv = mpc8220_fec_recv;
- sprintf (dev-name, FEC ETHERNET);
+ sprintf (dev-name, FEC_ETHERNET);
eth_register (dev);
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
diff --git a/arch/powerpc/cpu/mpc8xx/fec.c b/arch/powerpc/cpu/mpc8xx/fec.c
index 89c1ff9..73f1f98 100644
--- a/arch/powerpc/cpu/mpc8xx/fec.c
+++ b/arch/powerpc/cpu/mpc8xx/fec.c
@@ -164,9 +164,9 @@ int fec_initialize(bd_t *bis)
/* for FEC1 make sure that the name of the interface is the same
as the old one for compatibility reasons */
if (i == 0) {
- sprintf (dev-name, FEC ETHERNET);
+ sprintf (dev-name, FEC_ETHERNET);
} else {
- sprintf (dev-name, FEC%d ETHERNET,
+ sprintf (dev-name, FEC%d_ETHERNET,
ether_fcc_info[i].ether_index + 1);
}
diff --git a/board/motionpro/motionpro.c b/board/motionpro/motionpro.c
index b369219..3616791 100644
--- a/board/motionpro/motionpro.c
+++ b/board/motionpro/motionpro.c
@@ -90,8 +90,8 @@ void reset_phy(void)
{
unsigned short mode_control;
- miiphy_read(FEC ETHERNET, CONFIG_PHY_ADDR, 0x15, mode_control);
- miiphy_write(FEC ETHERNET, CONFIG_PHY_ADDR, 0x15,
+ miiphy_read(FEC_ETHERNET, CONFIG_PHY_ADDR, 0x15, mode_control);
+ miiphy_write(FEC_ETHERNET, CONFIG_PHY_ADDR, 0x15,
mode_control 0xfffe);
return;
}
diff --git a/board/stx/stxxtc/stxxtc.c b/board/stx/stxxtc/stxxtc.c
index 717dbe2..d9f7a2d 100644
--- a/board/stx/stxxtc/stxxtc.c
+++ b/board/stx/stxxtc/stxxtc.c
@@ -481,12 +481,12 @@ void reset_phys(void)
mii_init();
for (phyno = 0; phyno 32; ++phyno) {
- miiphy_read(FEC ETHERNET, phyno, PHY_PHYIDR1, v);
+ miiphy_read(FECETHERNET, phyno, PHY_PHYIDR1, v);
if (v == 0x)
continue;
- miiphy_write(FEC ETHERNET, phyno, PHY_BMCR, PHY_BMCR_POWD);
+ miiphy_write(FEC_ETHERNET, phyno, PHY_BMCR, PHY_BMCR_POWD);
udelay(1);
- miiphy_write(FEC ETHERNET, phyno, PHY_BMCR, PHY_BMCR_RESET |
PHY_BMCR_AUTON);
+ miiphy_write(FEC_ETHERNET, phyno, PHY_BMCR, PHY_BMCR_RESET |
PHY_BMCR_AUTON);
udelay(1);
}
}
diff --git a/board/tqc/tqm8xx/tqm8xx.c b/board/tqc/tqm8xx/tqm8xx.c
index 53f79e8..3ca2ee7 100644
--- a/board/tqc/tqm8xx/tqm8xx.c
+++ b/board/tqc/tqm8xx/tqm8xx.c
@@ -745,13 +745,13 @@ int last_stage_init(void)
return 0;
for (i = 0; i 2; i++) {
- ret = miiphy_read(FEC ETHERNET, phy[i], PHY_BMCR, reg);
+ ret = miiphy_read(FEC_ETHERNET, phy[i], PHY_BMCR, reg);
if (ret) {
printf(Cannot read BMCR on PHY %d\n, phy[i]);
return 0;
}
/* Auto-negotiation off, hard set full duplex, 100Mbps */
- ret = miiphy_write(FEC ETHERNET, phy[i],
+ ret = miiphy_write(FEC_ETHERNET, phy[i],
PHY_BMCR, (reg | PHY_BMCR_100MB |
PHY_BMCR_DPLX) ~PHY_BMCR_AUTON);
if (ret) {
diff --git a/drivers/net/mpc512x_fec.c b/drivers/net/mpc512x_fec.c
index c580c82..1f7392e 100644
--- a/drivers/net/mpc512x_fec.c
+++ b/drivers/net/mpc512x_fec.c
@@ -637,7 +637,7 @@ int mpc512x_fec_initialize (bd_t * bis)
dev-send = mpc512x_fec_send;
dev-recv = mpc512x_fec_recv;
- sprintf (dev-name, FEC ETHERNET);
+ sprintf (dev-name, FEC_ETHERNET);
eth_register (dev);
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
diff --git a/drivers/net/mpc5xxx_fec.c b/drivers/net/mpc5xxx_fec.c
index
[U-Boot] [PATCH-V3] at91: Update meesc board to new SoC access
* convert meesc board to use c stucture SoC access
* change gpio access to at91_gpio syntax
* moved CONFIG_SYS_HZ below board and cpu defines (purely cosmetic)
Signed-off-by: Daniel Gorsulowski daniel.gorsulow...@esd.eu
---
v2: fixed copyright changing error according to Wolfgangs hint
v3: removed some whitespace, indentation and coding style errors
board/esd/meesc/meesc.c | 112 --
include/configs/meesc.h |9 ++--
2 files changed, 62 insertions(+), 59 deletions(-)
diff --git a/board/esd/meesc/meesc.c b/board/esd/meesc/meesc.c
index a1b66cb..eb87cfc 100644
--- a/board/esd/meesc/meesc.c
+++ b/board/esd/meesc/meesc.c
@@ -3,7 +3,7 @@
* Stelian Pop stelian@leadtechdesign.com
* Lead Tech Design www.leadtechdesign.com
*
- * (C) Copyright 2009
+ * (C) Copyright 2009-2010
* Daniel Gorsulowski daniel.gorsulow...@esd.eu
* esd electronic system design gmbh www.esd.eu
*
@@ -28,13 +28,13 @@
#include common.h
#include asm/arch/at91sam9263.h
-#include asm/arch/at91sam9_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/at91_matrix.h
+#include asm/arch/at91_pio.h
#include asm/arch/clk.h
-#include asm/arch/gpio.h
#include asm/arch/hardware.h
#include asm/arch/io.h
#include netdev.h
@@ -52,10 +52,10 @@ int get_hw_rev(void)
if (hw_rev = 0)
return hw_rev;
- hw_rev = at91_get_gpio_value(AT91_PIN_PB19);
- hw_rev |= at91_get_gpio_value(AT91_PIN_PB20) 1;
- hw_rev |= at91_get_gpio_value(AT91_PIN_PB21) 2;
- hw_rev |= at91_get_gpio_value(AT91_PIN_PB22) 3;
+ hw_rev = at91_get_pio_value(AT91_PIO_PORTB, 19);
+ hw_rev |= at91_get_pio_value(AT91_PIO_PORTB, 20) 1;
+ hw_rev |= at91_get_pio_value(AT91_PIO_PORTB, 21) 2;
+ hw_rev |= at91_get_pio_value(AT91_PIO_PORTB, 22) 3;
if (hw_rev == 15)
hw_rev = 0;
@@ -67,44 +67,44 @@ int get_hw_rev(void)
static void meesc_nand_hw_init(void)
{
unsigned long csa;
+ at91_smc_t *smc= (at91_smc_t *) AT91_SMC0_BASE;
+ at91_matrix_t *matrix = (at91_matrix_t *) AT91_MATRIX_BASE;
/* Enable CS3 */
- csa = at91_sys_read(AT91_MATRIX_EBI0CSA);
- at91_sys_write(AT91_MATRIX_EBI0CSA,
- csa | AT91_MATRIX_EBI0_CS3A_SMC_SMARTMEDIA);
+ csa = readl(matrix-csa[0]) | AT91_MATRIX_CSA_EBI_CS3A;
+ writel(csa, matrix-csa[0]);
/* 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_(3) | AT91_SMC_NCS_WRPULSE_(3) |
- AT91_SMC_NRDPULSE_(3) | AT91_SMC_NCS_RDPULSE_(3));
- at91_sys_write(AT91_SMC_CYCLE(3),
- AT91_SMC_NWECYCLE_(5) | AT91_SMC_NRDCYCLE_(5));
- at91_sys_write(AT91_SMC_MODE(3),
- AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
- AT91_SMC_EXNWMODE_DISABLE |
-#ifdef CONFIG_SYS_NAND_DBW_16
- AT91_SMC_DBW_16 |
-#else /* CONFIG_SYS_NAND_DBW_8 */
- AT91_SMC_DBW_8 |
-#endif
- AT91_SMC_TDF_(2));
+ 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(3) | AT91_SMC_PULSE_NCS_WR(3) |
+ AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(3),
+ smc-cs[3].pulse);
+
+ writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(5),
+ smc-cs[3].cycle);
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+ AT91_SMC_MODE_EXNW_DISABLE |
+ AT91_SMC_MODE_DBW_8 |
+ AT91_SMC_MODE_TDF_CYCLE(2),
+ smc-cs[3].mode);
/* Configure RDY/BSY */
- at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
+ at91_set_pio_input(CONFIG_SYS_NAND_READY_PIN, 1);
/* Enable NandFlash */
- at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
+ at91_set_pio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
}
#endif /* CONFIG_CMD_NAND */
#ifdef CONFIG_MACB
static void meesc_macb_hw_init(void)
{
+ at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
/* Enable clock */
- at91_sys_write(AT91_PMC_PCER, 1 AT91SAM9263_ID_EMAC);
+ writel(1 AT91SAM9263_ID_EMAC, pmc-pcer);
at91_macb_hw_init();
}
#endif
@@ -117,26 +117,27 @@ static void meesc_macb_hw_init(void)
*/
static void meesc_ethercat_hw_init(void)
{
+ at91_smc_t *smc1 = (at91_smc_t *) AT91_SMC1_BASE;
+
/* Configure SMC EBI1_CS0 for EtherCAT */
- at91_sys_write(AT91_SMC1_SETUP(0),
- AT91_SMC_NWESETUP_(0) | AT91_SMC_NCS_WRSETUP_(0) |
-
Re: [U-Boot] Non standard CFI detection tweaks
On 2010/07/19 1:50 PM, Stefan Roese wrote: This is quite odd, though. DNS323B1 mw.w 0xff800555 00aa .. never returns. It seems to hang up the board for some reason. Ahh, unaligned 16bit access on ARM. Please give these commands another try: = mw.w ff800aaa 00aa = mw.w ff800554 0055 = mw.w ff800aaa 0090 = md.w ff80 Cheers, Stefan DNS323B1 mw.w ff800aaa 00aa DNS323B1 mw.w ff800554 0055 DNS323B1 mw.w ff800aaa 0090 DNS323B1 md.w ff80 ff80: ff800010: ff800020: ff800030: ff800040: ff800050: ff800060: ff800070: I also tried various permutations of mw.w ff8000aa 00aa, etc, as well as mw.w 0xff800554 5500 (rather than 0055), since we are writing to a different address, and none of them gave anything other than results. This is the procedure for entering QRY mode, though, from my original email: For this particular chip, the command is: mw.w 0xff8000aa 9800 (rather than 9898) (FWIW mw.b 0xff8000aa 98 also works fine to enter QRY mode) Having done that, the QRY results are present at 0xff800020: md.b ff800020 20 ff800020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 QQRRYY@@ ff800030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 04 04 ..''66.. Does that help? Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Add CONFIG_DDR_RFDC_FIXED to allow board specific RFDC values
Using this define, a board can define an opimized RFDC value and use the auto calibration code to tune the remaining DDR2 controller calibration register. Signed-off-by: Stefan Roese s...@denx.de --- arch/powerpc/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c b/arch/powerpc/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c index 0f69ef9..5e35c61 100644 --- a/arch/powerpc/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c +++ b/arch/powerpc/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c @@ -767,6 +767,13 @@ static u32 DQS_calibration_methodB(struct ddrautocal *cal) debug(\n\n); +#if defined(CONFIG_DDR_RFDC_FIXED) + mtsdram(SDRAM_RFDC, CONFIG_DDR_RFDC_FIXED); + size = 512; + rffd_average = CONFIG_DDR_RFDC_FIXED SDRAM_RFDC_RFFD_MASK; + mfsdram(SDRAM_RDCC, rdcc); /* record this value */ + cal-rdcc = rdcc; +#else in_window = 0; rdcc = 0; @@ -830,6 +837,7 @@ static u32 DQS_calibration_methodB(struct ddrautocal *cal) rffd_average = SDRAM_RFDC_RFFD_MAX; mtsdram(SDRAM_RFDC, rfdc_reg | SDRAM_RFDC_RFFD_ENCODE(rffd_average)); +#endif rffd = rffd_average; in_window = 0; @@ -1211,10 +1219,14 @@ u32 DQS_autocalibration(void) debug(*** best_result: read value SDRAM_RQDC 0x%08x\n, rqdc_reg); +#if defined(CONFIG_DDR_RFDC_FIXED) + mtsdram(SDRAM_RFDC, CONFIG_DDR_RFDC_FIXED); +#else mfsdram(SDRAM_RFDC, rfdc_reg); rfdc_reg = ~(SDRAM_RFDC_RFFD_MASK); mtsdram(SDRAM_RFDC, rfdc_reg | SDRAM_RFDC_RFFD_ENCODE(tcal.autocal.rffd)); +#endif mfsdram(SDRAM_RFDC, rfdc_reg); debug(*** best_result: read value SDRAM_RFDC 0x%08x\n, -- 1.7.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: T3CORP fixes and updates
This patch fixes some problems for the T3CORP board. Here the list
of the changes:
- Add 600-67 and 677 CPU frequency setting to chip_config
command
- Define CONFIG_DDR_RFDC_FIXED on t3corp:
While using the normal auto calibration code, sometimes values for
RFDC were picked (= T3) that resulted in a non-working U-Boot (hang
upon relocation, while running from SDRAM). With this optimized RFDC
value we can force this register and use the auto-calibration code to
setup the remaining calibration registers.
- Increase sizes of FPGA chips selects
- EBC timing updated OEN=3 for 66 MHz EBC speed
- Change ext. IRQ2 setup to level-low active
- Enable CONFIG_SYS_CFI_FLASH_STATUS_POLL
By defining CONFIG_SYS_CFI_FLASH_STATUS_POLL, DQ7 is polled to detect the
chip busy status. This is now used instead of the data toggle method which
is used historically by default in the common CFI driver. With this change
a problem with not written data is solved on this board, where a 32 byte
block of data is still erased instead of filled with the correct content
after these commands:
= erase 0xfc10 +0x100
.
done
Erased 128 sectors
= cp.b 0x10 0xfc10 0x100
Copy to Flash... done
= cmp.b 0x10 0xfc10 0x100
byte at 0x00d0d6c0 (0x00) != byte at 0xfcd0d6c0 (0xff)
Total of 12637888 bytes were the same
Signed-off-by: Stefan Roese s...@denx.de
---
board/t3corp/chip_config.c | 16 +++-
board/t3corp/init.S|8 +---
board/t3corp/t3corp.c |2 +-
include/configs/t3corp.h | 27 +--
4 files changed, 34 insertions(+), 19 deletions(-)
diff --git a/board/t3corp/chip_config.c b/board/t3corp/chip_config.c
index c00bf16..98ab49f 100644
--- a/board/t3corp/chip_config.c
+++ b/board/t3corp/chip_config.c
@@ -27,13 +27,27 @@
struct ppc4xx_config ppc4xx_config_val[] = {
{
- 600, CPU: 600 PLB: 200 OPB: 100 EBC: 100,
+ 600-67, CPU: 600 PLB: 200 OPB: 67 EBC: 67,
+ {
+ 0x86, 0x80, 0xce, 0x1f, 0x7d, 0x80, 0x00, 0xe0,
+ 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ }
+ },
+ {
+ 600-100, CPU: 600 PLB: 200 OPB: 100 EBC: 100,
{
0x86, 0x80, 0xce, 0x1f, 0x79, 0x80, 0x00, 0xa0,
0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
}
},
{
+ 667, CPU: 667 PLB: 166 OPB: 83 EBC: 83,
+ {
+ 0x06, 0x80, 0xbb, 0x14, 0x99, 0x82, 0x00, 0xa0,
+ 0x40, 0x88, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ }
+ },
+ {
800, CPU: 800 PLB: 200 OPB: 100 EBC: 100,
{
0x86, 0x80, 0xba, 0x14, 0x99, 0x80, 0x00, 0xa0,
diff --git a/board/t3corp/init.S b/board/t3corp/init.S
index 4a4217f..ecd35ff 100644
--- a/board/t3corp/init.S
+++ b/board/t3corp/init.S
@@ -81,11 +81,13 @@ tlbtab:
tlbentry(CONFIG_SYS_PCIE_BASE, SZ_16K, 0x0801, 0xc, AC_RW | SA_IG)
/* TLB-entry for FPGA(s) */
- tlbentry(CONFIG_SYS_FPGA1_BASE, SZ_1M, CONFIG_SYS_FPGA1_BASE, 4,
+ tlbentry(CONFIG_SYS_FPGA1_BASE, SZ_16M, CONFIG_SYS_FPGA1_BASE, 4,
AC_RW | SA_IG)
- tlbentry(CONFIG_SYS_FPGA2_BASE, SZ_1M, CONFIG_SYS_FPGA2_BASE, 4,
+ tlbentry(CONFIG_SYS_FPGA1_BASE + (16 20), SZ_16M,
+CONFIG_SYS_FPGA1_BASE + (16 20), 4, AC_RW | SA_IG)
+ tlbentry(CONFIG_SYS_FPGA2_BASE, SZ_16M, CONFIG_SYS_FPGA2_BASE, 4,
AC_RW | SA_IG)
- tlbentry(CONFIG_SYS_FPGA3_BASE, SZ_1M, CONFIG_SYS_FPGA3_BASE, 4,
+ tlbentry(CONFIG_SYS_FPGA3_BASE, SZ_16M, CONFIG_SYS_FPGA3_BASE, 4,
AC_RW | SA_IG)
/* TLB-entry for OCM */
diff --git a/board/t3corp/t3corp.c b/board/t3corp/t3corp.c
index 8ffa321..ddf5897 100644
--- a/board/t3corp/t3corp.c
+++ b/board/t3corp/t3corp.c
@@ -45,7 +45,7 @@ int board_early_init_f(void)
mtdcr(UIC1SR, 0x); /* clear all */
mtdcr(UIC1ER, 0x); /* disable all */
mtdcr(UIC1CR, 0x); /* all non-critical */
- mtdcr(UIC1PR, 0x); /* per ref-board manual */
+ mtdcr(UIC1PR, 0x7fff); /* per ref-board manual */
mtdcr(UIC1TR, 0x); /* per ref-board manual */
mtdcr(UIC1VR, 0x); /* int31 highest, base=0x000 */
mtdcr(UIC1SR, 0x); /* clear all */
diff --git a/include/configs/t3corp.h b/include/configs/t3corp.h
index 0ecc5b1..7b88601 100644
--- a/include/configs/t3corp.h
+++ b/include/configs/t3corp.h
@@ -74,8 +74,8 @@
#define CONFIG_SYS_FLASH_SIZE (64 20)
#define CONFIG_SYS_FPGA1_BASE 0xe000
-#define CONFIG_SYS_FPGA2_BASE 0xe010
-#define CONFIG_SYS_FPGA3_BASE 0xe020
+#define
[U-Boot] [PATCH] NAND: add Samsung K9LBG08UXD identifier
The Samsung K9LBG08UXD parts are 32Gbytes x 8 bits 3.3V parts with
the 0xD7 identifier. Add this to the list of known devices IDs.
Signed-off-by: Lei Wen lei...@marvell.com
---
drivers/mtd/nand/nand_ids.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 25b22ec..3d958d8 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -111,6 +111,9 @@ struct nand_flash_dev nand_flash_ids[] = {
{NAND 2GiB 1,8V 16-bit, 0xB5, 0, 2048, 0, LP_OPTIONS16},
{NAND 2GiB 3,3V 16-bit, 0xC5, 0, 2048, 0, LP_OPTIONS16},
+ /* 32 Gigabit */
+ {NAND 4GiB 3,3V 8-bit,0xD7, 0, 4096, 0, LP_OPTIONS16},
+
/*
* Renesas AND 1 Gigabit. Those chips do not support extended id and
* have a strange page/block layout ! The chosen minimum erasesize is
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: add Samsung K9LBG08UXD identifier
Rebased version for this nand chip has one problem in detecting its
page size using in nand_base.c.
If we set page size 0 in nand_ids.c, we would get the calculation
result as page size 2048, while the true page size is 4096.
I think it is reasonable to set the 32Gigabit nand as 4k page by
default, as all nand been product in this size has
more than 4k page.
The Samsung K9LBG08UXD parts are 32Gbytes x 8 bits 3.3V parts with
the 0xD7 identifier. Add these to the list of known devices IDs.
Signed-off-by: Lei Wen lei...@marvell.com
---
drivers/mtd/nand/nand_ids.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 077c305..5dd4c54 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -110,6 +110,9 @@ struct nand_flash_dev nand_flash_ids[] = {
{NAND 2GiB 1,8V 16-bit, 0xB5, 0, 2048, 0, LP_OPTIONS16},
{NAND 2GiB 3,3V 16-bit, 0xC5, 0, 2048, 0, LP_OPTIONS16},
+ /* 32 Gigabit */
+ {NAND 4GiB 3,3V 8-bit,0xD7, 4096, 4096, 0, LP_OPTIONS},
+
/*
* Renesas AND 1 Gigabit. Those chips do not support extended id and
* have a strange page/block layout ! The chosen minimum erasesize is
On Mon, Jul 19, 2010 at 8:49 PM, Lei Wen adrian.w...@gmail.com wrote:
The Samsung K9LBG08UXD parts are 32Gbytes x 8 bits 3.3V parts with
the 0xD7 identifier. Add this to the list of known devices IDs.
Signed-off-by: Lei Wen lei...@marvell.com
---
drivers/mtd/nand/nand_ids.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 25b22ec..3d958d8 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -111,6 +111,9 @@ struct nand_flash_dev nand_flash_ids[] = {
{NAND 2GiB 1,8V 16-bit, 0xB5, 0, 2048, 0, LP_OPTIONS16},
{NAND 2GiB 3,3V 16-bit, 0xC5, 0, 2048, 0, LP_OPTIONS16},
+ /* 32 Gigabit */
+ {NAND 4GiB 3,3V 8-bit, 0xD7, 0, 4096, 0, LP_OPTIONS16},
+
/*
* Renesas AND 1 Gigabit. Those chips do not support extended id and
* have a strange page/block layout ! The chosen minimum erasesize is
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non standard CFI detection tweaks
On Monday 19 July 2010 14:18:37 Rogan Dawes wrote: DNS323B1 mw.w ff800aaa 00aa DNS323B1 mw.w ff800554 0055 DNS323B1 mw.w ff800aaa 0090 DNS323B1 md.w ff80 ff80: ff800010: ff800020: ff800030: ff800040: ff800050: ff800060: ff800070: I also tried various permutations of mw.w ff8000aa 00aa, etc, as well as mw.w 0xff800554 5500 (rather than 0055), since we are writing to a different address, and none of them gave anything other than results. Too bad. :-( This is the procedure for entering QRY mode, though, from my original email: For this particular chip, the command is: mw.w 0xff8000aa 9800 (rather than 9898) (FWIW mw.b 0xff8000aa 98 also works fine to enter QRY mode) Having done that, the QRY results are present at 0xff800020: md.b ff800020 20 ff800020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 QQRRYY@@ ff800030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 04 04 .''66.. Does that help? Not really. I find it odd, that writing 0x9800 works and 0x0098 doesn't. Perhaps the chip is connected in byte-mode after all? Not sure. Do you know if and how the Linux MTD driver handles the NOR FLASH? Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nor Flash SST39VF6402B cfi compliant support
This is the rigth config for such a FLASH chip
#ifdef CONFIG_SYS_FLASH_LEGACY_4Mx16
{
.mfr_id = (u16)SST_MANUFACT,
.dev_id = SST39VF6402B,
.name = SST 39VF6402B,
.uaddr = {
[1] = MTD_UADDR_0x0555_0x02AA /* x16 */
},
.DevSize= SIZE_4MiB,
.CmdSet = CFI_CMDSET_AMD_LEGACY,
.NumEraseRegions= 1,
.regions= {
ERASEINFO(0x1,128),
}
},
#endif
Best regards and thanks a lot
In data lunedì 19 luglio 2010 12:26:32, Fabio Giovagnini ha scritto:
: I supposed the list doesn't like the attachment.
Anyway I understand, now.
I'll make you know how I'll solve.
Thanks a lot and best regards
In data lunedì 19 luglio 2010 11:33:43, Stefan Roese ha scritto:
: Hi Fabio,
(please keep the list on Cc).
On Monday 19 July 2010 11:27:50 Fabio Giovagnini wrote:
I do not think so about teh different regons.
I attach the datasheet I found on the net and I cannot find anythink
about two different regions for
SST39VF6402B
Maybe I'm wrong.
Yes, you are wrong. ;) The manual mentions block-erase (32k) and
sector-erase (2k). Please check which one is used by the CFi commands
right now.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
--
Fabio Giovagnini
Aurion s.r.l.
P.I e C.F.
00885711200
skype: aurion.giovagnini
Tel. +39.051.594.78.24
Cell. +39.335.83.50.919
www.aurion-tech.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nor Flash SST39VF6402B cfi compliant support
On Monday 19 July 2010 15:57:09 Fabio Giovagnini wrote:
This is the rigth config for such a FLASH chip
#ifdef CONFIG_SYS_FLASH_LEGACY_4Mx16
{
.mfr_id = (u16)SST_MANUFACT,
.dev_id = SST39VF6402B,
.name = SST 39VF6402B,
.uaddr = {
[1] = MTD_UADDR_0x0555_0x02AA /* x16 */
},
.DevSize= SIZE_4MiB,
.CmdSet = CFI_CMDSET_AMD_LEGACY,
.NumEraseRegions= 1,
.regions= {
ERASEINFO(0x1,128),
}
},
#endif
Best regards and thanks a lot
So you've got it working. Good. Please submit a proper patch with this SST
flash support. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Need Help : OMAP3530 Mistral EVM
Hi All, I have downloaded u-boot-2010.06.tar.bz2 from Denx website, then tried to configure it, it didn't work, i used # make omap3530_config It says : make: *** No rule to make target `omap3530_config'. Stop. Then it did : cd /board/ti It says : beagle omap1510inn omap2420h4 omap730p2 tnetv107xevm evm omap1610inn omap5912osk sdp3430 But no OMAP3530 My question is : Does u-boot support OMAP3530 board ??? Please let me know. Regards, Sudipta ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non standard CFI detection tweaks
On 2010/07/19 3:33 PM, Stefan Roese wrote: Not really. I find it odd, that writing 0x9800 works and 0x0098 doesn't. Perhaps the chip is connected in byte-mode after all? Not sure. Do you know if and how the Linux MTD driver handles the NOR FLASH? Cheers, Stefan Here is the setup code from the Linux kernel: http://lxr.free-electrons.com/source/arch/arm/mach-orion5x/dns323-setup.c#L93 Which is used by: http://lxr.free-electrons.com/source/arch/arm/mach-orion5x/dns323-setup.c#L435 I don't know enough about the kernel to understand where it goes to from there. Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] guys, can you see some init code for davinci's chipselect bit width driving DM9000A?
thanks，you are right, it really init the chip through UBL.
BUT, there is also one question:
DM9000a 's driver has 8 bit accessing function:
#define CONFIG_DM9000_BASE0x0400
#define DM9000_IOCONFIG_DM9000_BASE
#define DM9000_DATA(CONFIG_DM9000_BASE+2) // (BA1,it's the 16bit
least significant bit (effective) )
#define DM9000_outb(d,r) ( *(volatile u8 *)r = d )
#define DM9000_inb(r) (*(volatile u8 *)r)
static u8 DM9000_ior(int reg)
{
DM9000_outb(reg, DM9000_IO);
return DM9000_inb(DM9000_DATA);
}
/*
Write a byte to I/O port
*/
static void DM9000_iow(int reg, u8 value)
{
DM9000_outb(reg, DM9000_IO);
DM9000_outb(value, DM9000_DATA);
}
and the davinci's chipselect space is 16bit. when accessing it as 8bit ,the
last bit(may be A-2 ?) will be effective, but the least significant bit(BA1)
will not be effective, am i wrong? how does it work?
2010/7/19 Stefano Babic sba...@denx.de
yaojin liu wrote:
hi:
dm9000a works as 16bit bus width. however, i have not seen any init code
for
the dm355's chipselect.
and by default ,the cs1 is 8bit bus width at reset. how doew it work?
I think the setup is done by the UBL provided by TI. U-boot is a 3-rd
stage bootloader for DM355. The RBL (Rom Bootloader) loads the UBL from
storage, that sets up the required peripherals (RAM / AEMIF), and then
loads u-boot.
u-boot does not set the a2cr register in the AEMIF interface, but the
UBL has already configured it for 16-bit access.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nor Flash SST39VF6402B cfi compliant support
Ok
Cheers
In data lunedì 19 luglio 2010 16:19:23, Stefan Roese ha scritto:
: On Monday 19 July 2010 15:57:09 Fabio Giovagnini wrote:
This is the rigth config for such a FLASH chip
#ifdef CONFIG_SYS_FLASH_LEGACY_4Mx16
{
.mfr_id = (u16)SST_MANUFACT,
.dev_id = SST39VF6402B,
.name = SST 39VF6402B,
.uaddr = {
[1] = MTD_UADDR_0x0555_0x02AA /* x16 */
},
.DevSize= SIZE_4MiB,
.CmdSet = CFI_CMDSET_AMD_LEGACY,
.NumEraseRegions= 1,
.regions= {
ERASEINFO(0x1,128),
}
},
#endif
Best regards and thanks a lot
So you've got it working. Good. Please submit a proper patch with this SST
flash support. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
--
Fabio Giovagnini
Aurion s.r.l.
P.I e C.F.
00885711200
skype: aurion.giovagnini
Tel. +39.051.594.78.24
Cell. +39.335.83.50.919
www.aurion-tech.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: Need Your Help
Dne Po 19. července 2010 17:29:48 StephenPaulraj Chinnadurai-ERS,HCLTech
napsal(a):
Hello Marek,
Hope you are doing well.
I registered with U-Boot@lists.denx.de list last week and came to know
about activities of the group.
You should possibly CC this mail into u-boot mailing list too.
I understand that your work is very tightly scheduled.
I have made the FFUART and CFI to work in my board.
ok
But LAN91C connect to the PXA270 in the static chip select 4 (nCS4) is
not working.
Do you have correct GPIO mux settings ? In this case GPIO80 as to be AF2, check
your GAFRx registers.
In /include/configs/hcl_pxa270.h file I have defined the following macro:
#define CONFIG_SMC9
#define CONFIG_SMC9_BASE0x1300
Are you sure about the 0x300 offset? That's actually toggling MA10:9 pins on.
Do you have these connected at all?
Try this:
+/*
+ * Networking Configuration
+ * SMC91C111 chip
+ */
+#ifdef CONFIG_CMD_NET
+#defineCONFIG_CMD_PING
+#defineCONFIG_CMD_DHCP
+#defineCONFIG_NET_MULTI
+
+#defineCONFIG_SMC9
+#defineCONFIG_SMC9_BASE0x1300
+
+#defineCONFIG_BOOTP_BOOTFILESIZE
+#defineCONFIG_BOOTP_BOOTPATH
+#defineCONFIG_BOOTP_GATEWAY
+#defineCONFIG_BOOTP_HOSTNAME
+
+#defineCONFIG_NETMASK 255.255.255.0
+#defineCONFIG_IPADDR 192.168.1.52
+#defineCONFIG_SERVERIP 192.168.1.51
+#endif
In board/hcl_pxa270/lowlevel_init.S file, I have assigned
MSC0 = 0x23F2B8F2
MSC1 = 0xCCD1
MSC2 = 0xB884
You don't need these ... see arch/arm/include/asm/arch-pxa/macro.h, everything
you need is already configured there. Check for example vpac270 board.
Then in the board_init() function which is in /board/hcl_pxa270/hclpxa270.c
file, I assigned: MSC0 = 0x7FF07FF0
MSC1 = 0x7FF07FF0
MSC2 = 0x7FF07FF0
You don't need that. The macros above do it for you. Again, check vpac270
board,
it's lowlevel_init.S, it's configs/vpac270.h etc. You'll see that these are
configured much earlier and you're only duplicating work.
All you need in your hclpxa270.c is this:
+#ifdef CONFIG_CMD_NET
+int board_eth_init(bd_t *bis)
+{
+ int rc = 0;
+#ifdef CONFIG_SMC9
+ rc = smc9_initialize(0, CONFIG_SMC9_BASE);
+#endif
+ return rc;
+}
+#endif
But still the Ethernet is not initialized and working(Ethernet LED is not
blinking):
Apart from the above modification, whether I need to do any other changes.
I am sending this mail personally, because you understand my problem (that
I am working in hcl customized board and not in the reference/development
board).
You should CC the mailing list anyway, because the knowledge I share with you
can help other people who will search the mailing list in future.
Also, could you share your patch for the hcl board? It might be easier to check
for grave bugs then.
Cheers
Thanks and Regards
Stephen Paulraj C
HCL Technologies Ltd.
D-12, Sidco Industrial Estate,
Ambattur, Chennai -58
Tel: +91 44 42004800 Extn: 2319
Mob:+91 9962583934
www.hcl.in
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot for rsk7203
There somewhere in the linux-sh galaxy something like that http://www.stlinux.com/u-boot/target-install? Thanks a lot In data venerdì 16 luglio 2010 08:31:55, Nobuhiro Iwamatsu ha scritto: : Hi, Fabio. 2010/7/14 Fabio Giovagnini fabio.giovagn...@aurion-tech.com: Hi nobuhiro san. Is it running really on rsk7203 u-boot? in the directory board/renesas/rsk7203 the file lowlevel_init.S defines PDCRL4_A but do not ise it. So if the port are not set as Data bus, how the sysstem can boot? I dont have rsk7203 board now. It is scheduled that it is at hand next week. I will examine it next week. Best regards, Nobuhiro -- Fabio Giovagnini Aurion s.r.l. P.I e C.F. 00885711200 skype: aurion.giovagnini Tel. +39.051.594.78.24 Cell. +39.335.83.50.919 www.aurion-tech.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: Need Your Help
-Original Message-
From: Marek Vasut [mailto:marek.va...@gmail.com]
Sent: Monday, July 19, 2010 9:11 PM
To: StephenPaulraj Chinnadurai-ERS,HCLTech
Cc: u-boot@lists.denx.de
Subject: Re: FW: Need Your Help
Dne Po 19. července 2010 17:29:48 StephenPaulraj Chinnadurai-ERS,HCLTech
napsal(a):
Hello Marek,
Hope you are doing well.
I registered with U-Boot@lists.denx.de list last week and came to know
about activities of the group.
You should possibly CC this mail into u-boot mailing list too.
Ok I hereafter I will do it.
I understand that your work is very tightly scheduled.
I have made the FFUART and CFI to work in my board.
ok
But LAN91C connect to the PXA270 in the static chip select 4 (nCS4) is
not working.
Do you have correct GPIO mux settings ? In this case GPIO80 as to be AF2, check
your GAFRx registers.
#define CONFIG_SYS_GAFR2_U_VAL 0x4109a401, which means GPIO80 is assigned AF2
for nCS4.
In /include/configs/hcl_pxa270.h file I have defined the following macro:
#define CONFIG_SMC9
#define CONFIG_SMC9_BASE0x1300
Are you sure about the 0x300 offset? That's actually toggling MA10:9 pins on.
Do you have these connected at all?
I really don't know what for the offset 0x300.
Try this:
+/*
+ * Networking Configuration
+ * SMC91C111 chip
+ */
+#ifdef CONFIG_CMD_NET
+#defineCONFIG_CMD_PING
+#defineCONFIG_CMD_DHCP
+#defineCONFIG_NET_MULTI
+
+#defineCONFIG_SMC9
+#defineCONFIG_SMC9_BASE0x1300
+
+#defineCONFIG_BOOTP_BOOTFILESIZE
+#defineCONFIG_BOOTP_BOOTPATH
+#defineCONFIG_BOOTP_GATEWAY
+#defineCONFIG_BOOTP_HOSTNAME
+
+#defineCONFIG_NETMASK 255.255.255.0
+#defineCONFIG_IPADDR 192.168.1.52
+#defineCONFIG_SERVERIP 192.168.1.51
+#endif
In board/hcl_pxa270/lowlevel_init.S file, I have assigned
MSC0 = 0x23F2B8F2
MSC1 = 0xCCD1
MSC2 = 0xB884
You don't need these ... see arch/arm/include/asm/arch-pxa/macro.h, everything
you need is already configured there. Check for example vpac270 board.
Yes not required.
Then in the board_init() function which is in /board/hcl_pxa270/hclpxa270.c
file, I assigned: MSC0 = 0x7FF07FF0
MSC1 = 0x7FF07FF0
MSC2 = 0x7FF07FF0
You don't need that. The macros above do it for you. Again, check vpac270
board,
it's lowlevel_init.S, it's configs/vpac270.h etc. You'll see that these are
configured much earlier and you're only duplicating work.
Ok, I will remove it.
All you need in your hclpxa270.c is this:
+#ifdef CONFIG_CMD_NET
+int board_eth_init(bd_t *bis)
+{
+ int rc = 0;
+#ifdef CONFIG_SMC9
+ rc = smc9_initialize(0, CONFIG_SMC9_BASE);
+#endif
+ return rc;
+}
+#endif
Already done it.
But still the Ethernet is not initialized and working(Ethernet LED is not
blinking):
Apart from the above modification, whether I need to do any other changes.
I am sending this mail personally, because you understand my problem (that
I am working in hcl customized board and not in the reference/development
board).
You should CC the mailing list anyway, because the knowledge I share with you
can help other people who will search the mailing list in future.
Also, could you share your patch for the hcl board? It might be easier to check
for grave bugs then.
Cheers
Thanks and Regards
Stephen Paulraj C
HCL Technologies Ltd.
D-12, Sidco Industrial Estate,
Ambattur, Chennai -58
Tel: +91 44 42004800 Extn: 2319
Mob:+91 9962583934
www.hcl.in
DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates.
Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any mail and
attachments please check them for viruses and defect.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] question about add new board to MAKEALL
Dear =?UTF-8?B?IlhpYW5nZnUgTGl1KOWImOWQkeWvjCki?=, In message 4c43c9a9.7020...@openmobilefree.net you wrote: before I apply the new board patches. the MAKEALL compile 359 boards. after I applied the new board patches. the MAKEALL still compile 359 boards. Then you obviously missed to add your board to the MAKEALL script. and the build log is the same. is that mean my patch is ok to send to mailist list?? No, on contrary. some git question: I try to update my local [next] branch with upstream. but I got this error: fatal: Couldn't find remote ref next. Try: git checkout master; git remote prune origin xian...@openmobilefree:~/u-boot/u-boot.git$ git pull origin next fatal: Couldn't find remote ref next There is no next branch in the mainline repository at this point of the release cycle. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You know, after a woman's raised a family and so on, she wants to start living her own life. Whose life she's _been_ living, then? - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] question about example/standalone/mips.lds
Dear =?UTF-8?B?IlhpYW5nZnUgTGl1KOWImOWQkeWvjCki?=, In message 4c43cabb.3070...@openmobilefree.net you wrote: in this file : example/standalone/mips.lds it indicate compile example as BIG mips. but my device is LITTLE mips. so I simply comment this line[1]. I found other boards compile fine. without any error. do I must compile this example? is that ok to comment this line? or what I need to to ? All MIPS boards in mainline build fine without such a change - both the BE and the LE ones. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm what passes for a Unix guru in my office. This is a frightening concept. - Lee Ann Goldstein, in 3k55ba$...@butch.lmsc.lockheed.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Add CONFIG_DDR_RFDC_FIXED to allow board specific RFDC values
Dear Stefan Roese, In message 1279542253-27041-1-git-send-email...@denx.de you wrote: Using this define, a board can define an opimized RFDC value and use the auto calibration code to tune the remaining DDR2 controller calibration register. ... @@ -767,6 +767,13 @@ static u32 DQS_calibration_methodB(struct ddrautocal *cal) debug(\n\n); +#if defined(CONFIG_DDR_RFDC_FIXED) + mtsdram(SDRAM_RFDC, CONFIG_DDR_RFDC_FIXED); + size = 512; + rffd_average = CONFIG_DDR_RFDC_FIXED SDRAM_RFDC_RFFD_MASK; + mfsdram(SDRAM_RDCC, rdcc); /* record this value */ + cal-rdcc = rdcc; +#else in_window = 0; rdcc = 0; @@ -830,6 +837,7 @@ static u32 DQS_calibration_methodB(struct ddrautocal *cal) rffd_average = SDRAM_RFDC_RFFD_MAX; mtsdram(SDRAM_RFDC, rfdc_reg | SDRAM_RFDC_RFFD_ENCODE(rffd_average)); +#endif In cases of such long blocks, where the ending #endif is many, many lines away, it is usually helpful to mark where the #endif belongs to: #endif /* CONFIG_DDR_RFDC_FIXED */ Please do this here, too. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm a programmer: I don't buy software, I write it. -- Tom Christiansen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] 8xx, kup4: add FDT support
On Mon, 19 Jul 2010 14:13:53 +0200
Heiko Schocher h...@denx.de wrote:
+int fdt_set_node_and_value(void *blob,
+ char *nodename,
+ char *regname,
+ void *var,
+ int size)
+{
+ int ret = 0;
+ int nodeoffset = 0;
+
+ nodeoffset = fdt_path_offset(blob, nodename);
+ if (nodeoffset = 0) {
+ ret = fdt_setprop(blob, nodeoffset, regname, var,
+ size);
+ if (ret 0) {
+ printf(%s: cannot set %s/%s property; err: %s\n,
+ __func__, nodename, regname, fdt_strerror(ret));
+ }
+ } else {
+ printf(%s: cannot find %s node err:%s\n, __func__,
+ nodename, fdt_strerror(nodeoffset));
+ }
+ return ret;
+}
How is this different from do_fixup_by_path()?
+/*
+ * update brg property in the blob
+ */
+void ft_blob_update(void *blob, bd_t *bd)
+{
+ uchar enetaddr[6];
+ ulong brg_data = 0;
+
+ /* BRG */
+ brg_data = cpu_to_be32(bd-bi_busfreq);
+ fdt_set_node_and_value(blob,
+ /soc/cpm, brg-frequency,
+ brg_data, sizeof(brg_data));
This binding is deprecated -- the device tree should have a brg node, in
which ft_cpu_setup() will fill in clock-frequency.
See Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt in Linux.
You can keep brg-frequency around in addition if you need to support kernels
from the short period of time that was old enough to not know about the brg
node, but new enough to support device trees at all. Maybe put it in
ft_cpu_setup(), replacing the existing fixup a couple of other 8xx
boards do (but not all of them).
+ /* MAC addr */
+ if (eth_getenv_enetaddr(ethaddr, enetaddr)) {
+ fdt_set_node_and_value(blob,
+ ethernet0, local-mac-address,
+ enetaddr, sizeof(u8) * 6);
+ }
ft_cpu_setup() calls fdt_fixup_ethernet() which should handle this.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net, fec: fix Warning: eth device name has a space! for FEC devices
Dear Heiko Schocher, In message 4c4441d1.7080...@denx.de you wrote: since commit 1384f3bb8a4f9066805b70c1418eda78ecb73fdd ethernet names with spaces drop a Warning: eth device name has a space! message. This patch fix it for FEC ETHERNET devices found on mpc512x, mpc5xxx, mpc8xx and mpc8220 boards. Thanks, but ... arch/powerpc/cpu/mpc8220/fec.c |2 +- arch/powerpc/cpu/mpc8xx/fec.c |4 ++-- board/motionpro/motionpro.c|4 ++-- board/stx/stxxtc/stxxtc.c |6 +++--- board/tqc/tqm8xx/tqm8xx.c |4 ++-- drivers/net/mpc512x_fec.c |2 +- drivers/net/mpc5xxx_fec.c |2 +- include/configs/NSCU.h |1 - include/configs/TK885D.h |6 +++--- include/configs/idmr.h |2 +- include/configs/v38b.h |2 +- 11 files changed, 17 insertions(+), 18 deletions(-) ... I think we should update the occurence of this string in the documentation as well, i. e. also update the README. While doing this, we should then fix the similar SCC ETHERNET as well; potentially affected files: README arch/powerpc/cpu/mpc8260/ether_scc.c arch/powerpc/cpu/mpc8xx/scc.c board/LEOX/elpt860/README.LEOX board/RPXlite_dw/README doc/README.PlanetCore include/configs/TQM855L.h include/configs/TQM855M.h include/configs/TQM860L.h include/configs/TQM860M.h include/configs/TQM862L.h include/configs/TQM862M.h include/configs/TQM866M.h include/configs/TQM885D.h include/configs/keymile-common.h include/configs/km8xx.h Add ditto for FCC* ETHERNET; potentially affected files: arch/powerpc/cpu/mpc8260/ether_fcc.c arch/powerpc/cpu/mpc85xx/ether_fcc.c diff --git a/arch/powerpc/cpu/mpc8220/fec.c b/arch/powerpc/cpu/mpc8220/fec.c index 5df9735..cf0ce4a 100644 --- a/arch/powerpc/cpu/mpc8220/fec.c +++ b/arch/powerpc/cpu/mpc8220/fec.c @@ -840,7 +840,7 @@ int mpc8220_fec_initialize (bd_t * bis) dev-send = mpc8220_fec_send; dev-recv = mpc8220_fec_recv; - sprintf (dev-name, FEC ETHERNET); + sprintf (dev-name, FEC_ETHERNET); eth_register (dev); I always wondered why we need such a long (and slow to type) name. I suggest we use this opportunity and change the name into a plain and simple FEC resp. SCC and FCC ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The nice thing about standards is that there are so many to choose from. - Andrew S. Tanenbaum ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] move the flash setup to #ifndef CONFIG_SYS_NO_FLASH
Dear xiangfu, In message 1279509256-4524-1-git-send-email-xian...@openmobilefree.net you wrote: in my Ben Nanonote board. there is no flash. I got a error about no CONFIG_SYS_FLASH_BASE define. so I move this line to #ifndef CONFIG_SYS_NO_FLASH I have tested with MAKEALL. no warning or error relate this patch. this patch is base on [master] branch commit: 1f82ff4777f360e92aa37bbbed647f7b9d9d2044 Signed-off-by: Xiangfu Liu xian...@sharism.cc --- arch/mips/lib/board.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/mips/lib/board.c b/arch/mips/lib/board.c index b2d113e..0af09c6 100644 --- a/arch/mips/lib/board.c +++ b/arch/mips/lib/board.c @@ -349,9 +349,9 @@ void board_init_r (gd_t *id, ulong dest_addr) size = flash_init(); display_flash_config (size); bd-bi_flashsize = size; + bd-bi_flashstart = CONFIG_SYS_FLASH_BASE; #endif - bd-bi_flashstart = CONFIG_SYS_FLASH_BASE; #if CONFIG_SYS_MONITOR_BASE == CONFIG_SYS_FLASH_BASE bd-bi_flashoffset = monitor_flash_len; /* reserved area for U-Boot */ #else This is not a good idea, as it will leave the bd-bi_flash* variables uninitialized. Rather explicitly set these to 0, please. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Don't you know anything? I should have thought anyone knows that who knows anything about anything... - Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] move the flash setup to #ifndef CONFIG_SYS_NO_FLASH
Dear xiangfu, In message 1279510479-5285-1-git-send-email-xian...@openmobilefree.net you wrote: From: Xiangfu Liu xian...@sharism.cc Hi Wolfgang Denk in my Ben Nanonote board. there is no flash. I got a error about no CONFIG_SYS_FLASH_BASE define. so I move this line to #ifndef CONFIG_SYS_NO_FLASH Is there any specific reason for posting the same message 4 times from two different mail addresses? Please stop doing this! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can fool some of the people all of the time, and You can fool all of the people some of the time, but You can't fool mom. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net, fec: fix Warning: eth device name has a space! for FEC devices
Wolfgang Denk wrote: I always wondered why we need such a long (and slow to type) name. I suggest we use this opportunity and change the name into a plain and simple FEC resp. SCC and FCC ? Then probably unify the rule even for other architectures. We have a FEC_MXC, too, for Freescale's i.MX processors. We can use FEC_PPC, SCC_PPC if we want to add the architecture name (I do not think is useful), or better set the name to FEC for fec_mxc.c, too. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net, fec: fix Warning: eth device name has a space! for FEC devices
Hi Stefano, On 7/19/2010 12:11 PM, Stefano Babic wrote: Wolfgang Denk wrote: I always wondered why we need such a long (and slow to type) name. I suggest we use this opportunity and change the name into a plain and simple FEC resp. SCC and FCC ? Then probably unify the rule even for other architectures. We have a FEC_MXC, too, for Freescale's i.MX processors. We can use FEC_PPC, SCC_PPC if we want to add the architecture name (I do not think is useful), or better set the name to FEC for fec_mxc.c, too. Best regards, Stefano Babic Unless you have a chip with both MXC and PPC FECs, which I doubt, I don't think the extra namespace buys anything. Saving a few keystrokes, on the other hand (no pun intended) is a good thing. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net, fec: fix Warning: eth device name has a space! for FEC devices
Dear Stefano Babic, In message 4c44a356.7090...@denx.de you wrote: I always wondered why we need such a long (and slow to type) name. I suggest we use this opportunity and change the name into a plain and simple FEC resp. SCC and FCC ? Then probably unify the rule even for other architectures. We have a Agreed. FEC_MXC, too, for Freescale's i.MX processors. We can use FEC_PPC, SCC_PPC if we want to add the architecture name (I do not think is useful), or better set the name to FEC for fec_mxc.c, too. Sounds good to me. Would you like to submit a patch? :-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Let's say the docs present a simplified view of reality...:-) - Larry Wall in 6...@jpl-devvax.jpl.nasa.gov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: add Samsung K9LBG08UXD identifier
On Mon, Jul 19, 2010 at 09:05:05PM +0800, Lei Wen wrote: Rebased version for this nand chip has one problem in detecting its page size using in nand_base.c. If we set page size 0 in nand_ids.c, we would get the calculation result as page size 2048, while the true page size is 4096. Is the ID data bad, or is there a bug in nand_get_flash_type(), or is it some new ID format that needs support? I think it is reasonable to set the 32Gigabit nand as 4k page by default, as all nand been product in this size has more than 4k page. more than? Are there larger page size NANDs out there? And if so, wouldn't hard-coding the page size at 4096 bytes be a problem? Is there zero possibility that a 2k page NAND in this size could be made in the future (e.g. for compatibility with controllers that don't support 4k pages)? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v3] 8xx, kup4: minor configuration changes
- nfs-options removed
- hda-sda changed
- mtd parts added
- loadaddress changed
- cmd-line length increased
- lcd stuff removed
- code cleanup
Signed-off-by: Klaus Heydeck heyd...@kieback-peter.de
---
- changes since v1:
- added comments from Wolfgang Denk
- fix Codingstyle issues
- rebased against current mainline
- changes since v2
fix boards.cfg entry for kup4x board
board/kup/common/kup.c | 54 --
board/kup/common/kup.h | 44 +++--
board/kup/kup4k/kup4k.c| 439 +---
board/kup/kup4k/s1d13706.h | 174 -
board/kup/kup4x/kup4x.c| 265 ---
boards.cfg |2 +-
include/configs/KUP4K.h| 169 ++
include/configs/KUP4X.h| 64
8 files changed, 427 insertions(+), 784 deletions(-)
delete mode 100644 board/kup/kup4k/s1d13706.h
diff --git a/board/kup/common/kup.c b/board/kup/common/kup.c
index 2418d59..38259a5 100644
--- a/board/kup/common/kup.c
+++ b/board/kup/common/kup.c
@@ -24,49 +24,61 @@
#include common.h
#include mpc8xx.h
#include kup.h
+#include asm/io.h
-int misc_init_f (void)
+
+int misc_init_f(void)
{
volatile immap_t *immap = (immap_t *) CONFIG_SYS_IMMR;
volatile sysconf8xx_t *siu = immap-im_siu_conf;
- while (siu-sc_sipend 0x2000) {
- /* printf(waiting for 5V VCC\n); */
- ;
+ while (in_be32(siu-sc_sipend) 0x2000) {
+ debug(waiting for 5V VCC\n);
}
/* RS232 / RS485 default is RS232 */
- immap-im_ioport.iop_padat = ~(PA_RS485);
- immap-im_ioport.iop_papar = ~(PA_RS485);
- immap-im_ioport.iop_paodr = ~(PA_RS485);
- immap-im_ioport.iop_padir |= (PA_RS485);
+ clrbits_be16(immap-im_ioport.iop_padat, PA_RS485);
+ clrbits_be16(immap-im_ioport.iop_papar, PA_RS485);
+ clrbits_be16(immap-im_ioport.iop_paodr, PA_RS485);
+ setbits_be16(immap-im_ioport.iop_padir, PA_RS485);
+
+ /* IO Reset min 1 msec */
+ setbits_be16(immap-im_ioport.iop_padat,
+(PA_RESET_IO_01 | PA_RESET_IO_02));
+ clrbits_be16(immap-im_ioport.iop_papar,
+(PA_RESET_IO_01 | PA_RESET_IO_02));
+ clrbits_be16(immap-im_ioport.iop_paodr,
+(PA_RESET_IO_01 | PA_RESET_IO_02));
+ setbits_be16(immap-im_ioport.iop_padir,
+(PA_RESET_IO_01 | PA_RESET_IO_02));
+ udelay(1000);
+ clrbits_be16(immap-im_ioport.iop_padat,
+(PA_RESET_IO_01 | PA_RESET_IO_02));
return (0);
}
-
#ifdef CONFIG_IDE_LED
-void ide_led (uchar led, uchar status)
+void ide_led(uchar led, uchar status)
{
volatile immap_t *immap = (immap_t *) CONFIG_SYS_IMMR;
/* We have one led for both pcmcia slots */
- if (status) { /* led on */
- immap-im_ioport.iop_padat = ~(PA_LED_YELLOW);
- } else {
- immap-im_ioport.iop_padat |= (PA_LED_YELLOW);
- }
+ if (status)
+ clrbits_be16(immap-im_ioport.iop_padat, PA_LED_YELLOW);
+ else
+ setbits_be16(immap-im_ioport.iop_padat, PA_LED_YELLOW);
}
#endif
-void poweron_key (void)
+void poweron_key(void)
{
volatile immap_t *immap = (immap_t *) CONFIG_SYS_IMMR;
- immap-im_ioport.iop_pcpar = ~(PC_SWITCH1);
- immap-im_ioport.iop_pcdir = ~(PC_SWITCH1);
+ clrbits_be16(immap-im_ioport.iop_pcpar, PC_SWITCH1);
+ clrbits_be16(immap-im_ioport.iop_pcdir, PC_SWITCH1);
- if (immap-im_ioport.iop_pcdat (PC_SWITCH1))
- setenv (key1, off);
+ if (in_be16(immap-im_ioport.iop_pcdat) (PC_SWITCH1))
+ setenv(key1, off);
else
- setenv (key1, on);
+ setenv(key1, on);
}
diff --git a/board/kup/common/kup.h b/board/kup/common/kup.h
index b736283..455848c 100644
--- a/board/kup/common/kup.h
+++ b/board/kup/common/kup.h
@@ -24,23 +24,33 @@
#ifndef __KUP_H
#define __KUP_H
-#define PA_8 0x0080
-#define PA_11 0x0010
-#define PA_12 0x0008
-
-#define PB_14 0x0002
-#define PB_17 0x4000
-
-#define PC_9 0x0040
-
-#define PA_RS485 PA_11 /* SCC1: 0=RS232 1=RS485 */
-#define PA_LED_YELLOWPA_8
-#define BP_USB_VCC PB_14 /* VCC for USB devices 0=vcc on,
1=vcc off*/
-#define PB_LCD_PWM PB_17 /* PB 17 */
-#define PC_SWITCH1 PC_9/* Reboot switch */
-
-extern void poweron_key (void);
-
+#define PA_8 0x0080
+#define PA_9 0x0040
+#define PA_10 0x0020
+#define PA_11 0x0010
+#define PA_12 0x0008
+
+#define PB_14 0x0002
+#define PB_15 0x0001
+#define PB_16 0x8000
+#define PB_17 0x4000
+
+#define PC_4 0x0800
+#define PC_5 0x0400
+#define PC_9 0x0040
+
+#define PA_RS485 PA_11 /* SCC1: 0=RS232 1=RS485 */
[U-Boot] [PATCH 2/2 v3] 8xx, kup4: add FDT support
Signed-off-by: Heiko Schocher h...@denx.de
---
- changes since v1
- rebased against current mainline
- fix printf output
- changes since v2
added comments from Scott Wood
removed ft_blob_update() complete, because fixups are done in
cpu specific code.
board/kup/kup4k/kup4k.c | 11 +++
include/configs/KUP4K.h |4
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/board/kup/kup4k/kup4k.c b/board/kup/kup4k/kup4k.c
index 7eb36ab..267821c 100644
--- a/board/kup/kup4k/kup4k.c
+++ b/board/kup/kup4k/kup4k.c
@@ -24,6 +24,7 @@
#include common.h
#include command.h
+#include libfdt.h
#include mpc8xx.h
#include hwconfig.h
#include i2c.h
@@ -291,3 +292,13 @@ static unsigned char swapbyte(unsigned char c)
}
return result;
}
+
+/*
+ * Device Tree Support
+ */
+#if defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_OF_LIBFDT)
+void ft_board_setup(void *blob, bd_t *bd)
+{
+ ft_cpu_setup(blob, bd);
+}
+#endif /* defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_OF_LIBFDT) */
diff --git a/include/configs/KUP4K.h b/include/configs/KUP4K.h
index ab708ae..14d412d 100644
--- a/include/configs/KUP4K.h
+++ b/include/configs/KUP4K.h
@@ -510,5 +510,9 @@
#define CONFIG_SYS_DEVICE_NULLDEV 1 /* enble null device
*/
#define CONFIG_VERSION_VARIABLE1
+/* pass open firmware flat tree */
+#define CONFIG_OF_LIBFDT 1
+#define CONFIG_OF_BOARD_SETUP 1
+
#endif /* __CONFIG_H */
--
1.6.2.5
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] net, fec: fix Warning: eth device name has a space! for FEC devices
since commit 1384f3bb8a4f9066805b70c1418eda78ecb73fdd ethernet names with spaces drop a Warning: eth device name has a space! message. This patch fix it for: - FEC ETHERNET devices found on mpc512x, mpc5xxx, mpc8xx and mpc8220 boards. renamed to FEC. - SCC ETHERNET devices found on mpc8xx, mpc82xx based boards. Renamed to SCC. - HDLC ETHERNET devices found on mpc8xx boards Renamed to HDLC - FCC ETHERNET devices found on mpc8260 and mpc85xx based boards. Renamed to FCC Tested on the kup4k board. Signed-off-by: Heiko Schocher h...@denx.de --- - changes since v1: - added comment from Wolfgang Denk - add SCC and FCC devices - add HDLC device - fixed all (hopefully) occurences README |8 arch/powerpc/cpu/mpc8220/fec.c |2 +- arch/powerpc/cpu/mpc8260/ether_fcc.c |2 +- arch/powerpc/cpu/mpc8260/ether_scc.c |2 +- arch/powerpc/cpu/mpc85xx/ether_fcc.c |2 +- arch/powerpc/cpu/mpc8xx/fec.c|4 ++-- arch/powerpc/cpu/mpc8xx/scc.c|2 +- board/LEOX/elpt860/README.LEOX |8 board/RPXlite_dw/README |4 ++-- board/freescale/mpc8560ads/mpc8560ads.c |2 +- board/funkwerk/vovpn-gw/vovpn-gw.c |2 +- board/keymile/common/keymile_hdlc_enet.c |4 ++-- board/keymile/km8xx/km8xx_hdlc_enet.c|2 +- board/motionpro/motionpro.c |4 ++-- board/sbc8560/sbc8560.c |2 +- board/stx/stxgp3/stxgp3.c|2 +- board/stx/stxssa/stxssa.c|2 +- board/stx/stxxtc/stxxtc.c|6 +++--- board/tqc/tqm8xx/tqm8xx.c|4 ++-- doc/README.PlanetCore|2 +- doc/README.alaska8220|6 +++--- doc/uImage.FIT/howto.txt |4 ++-- drivers/net/mpc512x_fec.c|2 +- drivers/net/mpc5xxx_fec.c|2 +- include/configs/NSCU.h |1 - include/configs/TK885D.h |6 +++--- include/configs/TQM855L.h|2 +- include/configs/TQM855M.h|2 +- include/configs/TQM860L.h|2 +- include/configs/TQM860M.h|2 +- include/configs/TQM862L.h|2 +- include/configs/TQM862M.h|2 +- include/configs/TQM866M.h|2 +- include/configs/TQM885D.h|2 +- include/configs/ep82xxm.h|2 +- include/configs/idmr.h |2 +- include/configs/keymile-common.h |4 ++-- include/configs/km8xx.h |2 +- include/configs/v38b.h |2 +- 39 files changed, 57 insertions(+), 58 deletions(-) diff --git a/README b/README index a9c98f2..22c2a71 100644 --- a/README +++ b/README @@ -3148,10 +3148,10 @@ List of environment variables (most likely not complete): interface is currently active. For example you can do the following - = setenv ethact FEC ETHERNET - = ping 192.168.0.1 # traffic sent on FEC ETHERNET - = setenv ethact SCC ETHERNET - = ping 10.0.0.1 # traffic sent on SCC ETHERNET + = setenv ethact FEC + = ping 192.168.0.1 # traffic sent on FEC + = setenv ethact SCC + = ping 10.0.0.1 # traffic sent on SCC ethrotate- When set to no U-Boot does not go through all available network interfaces. diff --git a/arch/powerpc/cpu/mpc8220/fec.c b/arch/powerpc/cpu/mpc8220/fec.c index 5df9735..9a6d434 100644 --- a/arch/powerpc/cpu/mpc8220/fec.c +++ b/arch/powerpc/cpu/mpc8220/fec.c @@ -840,7 +840,7 @@ int mpc8220_fec_initialize (bd_t * bis) dev-send = mpc8220_fec_send; dev-recv = mpc8220_fec_recv; - sprintf (dev-name, FEC ETHERNET); + sprintf (dev-name, FEC); eth_register (dev); #if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) diff --git a/arch/powerpc/cpu/mpc8260/ether_fcc.c b/arch/powerpc/cpu/mpc8260/ether_fcc.c index 5ac02a0..c82958d 100644 --- a/arch/powerpc/cpu/mpc8260/ether_fcc.c +++ b/arch/powerpc/cpu/mpc8260/ether_fcc.c @@ -383,7 +383,7 @@ int fec_initialize(bd_t *bis) dev = (struct eth_device*) malloc(sizeof *dev); memset(dev, 0, sizeof *dev); - sprintf(dev-name, FCC%d ETHERNET, + sprintf(dev-name, FCC%d, ether_fcc_info[i].ether_index + 1); dev-priv = ether_fcc_info[i]; dev-init = fec_init; diff --git a/arch/powerpc/cpu/mpc8260/ether_scc.c b/arch/powerpc/cpu/mpc8260/ether_scc.c index 432111d..2870a9c 100644 --- a/arch/powerpc/cpu/mpc8260/ether_scc.c +++ b/arch/powerpc/cpu/mpc8260/ether_scc.c @@ -375,7 +375,7 @@ int mpc82xx_scc_enet_initialize(bd_t *bis) dev = (struct
Re: [U-Boot] [PATCH v2] net, fec: fix Warning: eth device name has a space! for FEC devices
Dear Heiko Schocher, In message 4c44c8f9.6020...@denx.de you wrote: since commit 1384f3bb8a4f9066805b70c1418eda78ecb73fdd ethernet names with spaces drop a Warning: eth device name has a space! message. This patch fix it for: - FEC ETHERNET devices found on mpc512x, mpc5xxx, mpc8xx and mpc8220 boards. renamed to FEC. - SCC ETHERNET devices found on mpc8xx, mpc82xx based boards. Renamed to SCC. - HDLC ETHERNET devices found on mpc8xx boards Renamed to HDLC - FCC ETHERNET devices found on mpc8260 and mpc85xx based boards. Renamed to FCC The Subject: (which is way too long, btw.) does not match the content of this patch. I'm not sure if it is a good idea to change the board specific README's. For example, board/LEOX/elpt860/README.LEOX shows U-Boot 0.2.2 ... ... Net: SCC ETHERNET For this specific version, the string was correct. Changing it is technically not correct. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The goal of science is to build better mousetraps. The goal of nature is to build better mice. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] net, fec: fix Warning: eth device name has a space! for FEC devices
Hi Heiko, On 7/19/2010 3:57 PM, Wolfgang Denk wrote: Dear Heiko Schocher, In message4c44c8f9.6020...@denx.de you wrote: since commit 1384f3bb8a4f9066805b70c1418eda78ecb73fdd ethernet names with spaces drop a Warning: eth device name has a space! message. This patch fix it for: - FEC ETHERNET devices found on mpc512x, mpc5xxx, mpc8xx and mpc8220 boards. renamed to FEC. - SCC ETHERNET devices found on mpc8xx, mpc82xx based boards. Renamed to SCC. - HDLC ETHERNET devices found on mpc8xx boards Renamed to HDLC - FCC ETHERNET devices found on mpc8260 and mpc85xx based boards. Renamed to FCC The Subject: (which is way too long, btw.) does not match the content of this patch. I'm not sure if it is a good idea to change the board specific README's. For example, board/LEOX/elpt860/README.LEOX shows U-Boot 0.2.2 ... ... Net: SCC ETHERNET For this specific version, the string was correct. Changing it is technically not correct. Best regards, Wolfgang Denk I just ran MAKEALL on this and it's clean, so if you address Wolfgang's concerns we'll pull it in. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] New implementation for internal handling of environment variables.
On Sat, 17 Jul 2010 21:45:48 +0200
Wolfgang Denk w...@denx.de wrote:
- It would be nice if we could add wildcard support for environment
variables; this is needed for variable name auto-completion,
but it would also be nice to be able to say printenv ip* or
printenv *addr*
you were right - a grepenv/findenv/'env search' substring
implementation on top of this looks to be at least as expensive as a
full export operation :/
int var_complete(int argc, char * const argv[], char last_char, int maxv,
char *cmdv[])
{
+#if 0 /* need to reimplement */
ouch - this is u-boot's most useful feature :)
It would be good to know boot time overhead the initial import function
makes, esp. in terms of number of boot-time accesses to the
environment...
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: add Samsung K9LBG08UXD identifier
On Tue, Jul 20, 2010 at 4:22 AM, Scott Wood scottw...@freescale.com wrote: On Mon, Jul 19, 2010 at 09:05:05PM +0800, Lei Wen wrote: Rebased version for this nand chip has one problem in detecting its page size using in nand_base.c. If we set page size 0 in nand_ids.c, we would get the calculation result as page size 2048, while the true page size is 4096. Is the ID data bad, or is there a bug in nand_get_flash_type(), or is it some new ID format that needs support? Samsung seem modify the ID name rule, which make the calculation method nand_get_flash_type doesn't work. In mainline linux code, it give a hardcode way to identify this type of nand with new calculation method. I think it is reasonable to set the 32Gigabit nand as 4k page by default, as all nand been product in this size has more than 4k page. more than? Are there larger page size NANDs out there? 8k page nand exists, but they are for even larger nand, like 64Gb, or 128Gb. And if so, wouldn't hard-coding the page size at 4096 bytes be a problem? Is there zero possibility that a 2k page NAND in this size could be made in the future (e.g. for compatibility with controllers that don't support 4k pages)? Maybe we could post another patch for that kind of nand?... -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] question about add new board to MAKEALL
Hi Wolfgang Denk On 07/20/2010 01:45 AM, Wolfgang Denk wrote: Dear =?UTF-8?B?IlhpYW5nZnUgTGl1KOWImOWQkeWvjCki?=, In message4c43c9a9.7020...@openmobilefree.net you wrote: before I apply the new board patches. the MAKEALL compile 359 boards. after I applied the new board patches. the MAKEALL still compile 359 boards. Then you obviously missed to add your board to the MAKEALL script. and the build log is the same. is that mean my patch is ok to send to mailist list?? No, on contrary. ok. will keep working on that today. some git question: I try to update my local [next] branch with upstream. but I got this error: fatal: Couldn't find remote ref next. Try: git checkout master; git remote prune origin xian...@openmobilefree:~/u-boot/u-boot.git$ git pull origin next fatal: Couldn't find remote ref next There is no next branch in the mainline repository at this point of the release cycle. thanks for the info. Best regards, Wolfgang Denk thanks again :) -- Best Regards Xiangfu Liu http://www.openmobilefree.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] move the flash setup to #ifndef CONFIG_SYS_NO_FLASH
oh. very sorry about the same message. the git send-emails give me some error. so I thought the email don't sended. thanks for let me know :) On 07/20/2010 02:56 AM, Wolfgang Denk wrote: Dear xiangfu, In message1279510479-5285-1-git-send-email-xian...@openmobilefree.net you wrote: From: Xiangfu Liuxian...@sharism.cc Hi Wolfgang Denk in my Ben Nanonote board. there is no flash. I got a error about no CONFIG_SYS_FLASH_BASE define. so I move this line to #ifndef CONFIG_SYS_NO_FLASH Is there any specific reason for posting the same message 4 times from two different mail addresses? Please stop doing this! Best regards, Wolfgang Denk -- Best Regards Xiangfu Liu http://www.openmobilefree.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] MPC8308ERDB: minimal support for devboard from Freescale
Dear Kim Phillips,
In message 20100719193356.a02add7e.kim.phill...@freescale.com you wrote:
+++ b/arch/powerpc/cpu/mpc83xx/acr.c
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ *
+ * 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
+ */
+
+#include common.h
+#include asm/io.h
+
+void single_cline_write(volatile void *addr, __be32 val)
+{
+ out_be32(addr, val);
+}
Oops?? Why do we need a new file, with a new function, does nothing
else but calling another funtion, and that gets used just a single
time?
Drop this wrapper!
+++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
@@ -30,6 +30,8 @@
DECLARE_GLOBAL_DATA_PTR;
+extern void single_cline_write(volatile void *addr, __be32 val);
[Prototypes should always go to appropriate header files!!]
void cpu_init_f (volatile immap_t * im)
{
+ __be32 val;
__be32 acr_mask =
#ifdef CONFIG_SYS_ACR_PIPE_DEP /* Arbiter pipeline depth */
ACR_PIPE_DEP |
@@ -213,7 +216,8 @@ void cpu_init_f (volatile immap_t * im)
memset ((void *) gd, 0, sizeof (gd_t));
/* system performance tweaking */
- clrsetbits_be32(im-arbiter.acr, acr_mask, acr_val);
+ val = __raw_readl(im-arbiter.acr);
Do we need __raw_readl()? Why would in_be32() not work?
+ single_cline_write(im-arbiter.acr, acr_val (val ~acr_mask));
Make this:
out_be32(im-arbiter.acr, acr_val (val ~acr_mask));
+. = ALIGN(32);
+arch/powerpc/cpu/mpc83xx/acr.o (.text)
Ah! I guess this is worth a comment? But should we not rather aligh
the in_* and out_* functions then?
What is the exact use case when such alignment might be needed? Can
you guarantee that it's only with this specific register access, and
only for write accesses?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
... bacteriological warfare ... hard to believe we were once foolish
enough to play around with that.
-- McCoy, The Omega Glory, stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net, fec: Shorten device name as done for other drivers
After discussion on the ML it is suggested to drop unrequired and not useful characters from the device name. This patch changes the name for the fec_mxc driver from FEC_MXC to FEC. Signed-off-by: Stefano Babic sba...@denx.de --- drivers/net/fec_mxc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index 57f89a3..6b801ce 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -743,7 +743,7 @@ static int fec_probe(bd_t *bd) writel(0x05ee0024, fec-eth-r_cntrl); /* FIXME 0x05ee0004 */ fec_mii_setspeed(fec); - sprintf(edev-name, FEC_MXC); + sprintf(edev-name, FEC); miiphy_register(edev-name, fec_miiphy_read, fec_miiphy_write); -- 1.6.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
