Re: [U-Boot] [PATCH] ppc44x: config GPIOs for USB on canyonlands board
Also, when adding this code to usb_board_init(), would it not be logical to undo this initialization in usb_board_stop()? RUP Ok, I will include your suggestion and resubmit FKAN: Dear Wolfgang, is the symmetry needed here? If a user plan to use the usb, he will trigger the function. Otherwise, on a stop what value would we put it back to. 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 In theory, there is no difference between theory and practice. In practice, however, there is. ___ 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] [PATCH] ppc44x: config GPIOs for USB on canyonlands board
On Fri, Sep 24, 2010 at 10:43 AM, Wolfgang Denk w...@denx.de wrote: Dear Feng Kan, In message aanlktin-rbm0ndqzmzkcyp45-m9s+3h_fb7dwzzeh...@mail.gmail.com you wrote: FKAN: Dear Wolfgang, is the symmetry needed here? If a user plan to use the usb, he will trigger the function. Otherwise, on a stop what value would we put it back to. Design rules say: Shall initialize only such peripherals used by U-Boot itself, and must deinitialize them after use. Note that especially the deinitialization is mandatory! FKAN: I agree, thanks. However, this conflict with one of your other rule Don't make U-Boot slow. If another software entity wish to use the GPIO after, the code would deinit to gpio state and the other init would init gpio to the same state. Essentially doubling the code doing the same thing. Isn't this GPI reset to the initial values part of the deinitialization sequence? FKAN: In this case, gpio is double muxed in functionality. Do we need to remember state if the gpio is tri-muxed? 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 software required `Windows 95 or better', so I installed Linux. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] APM82xxx: Add bluestone board support
) */
+#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE 1
+/* print 'E' for empty sector on flinfo */
+#define CONFIG_SYS_FLASH_EMPTY_INFO
+#ifdef CONFIG_ENV_IS_IN_FLASH
+#define CONFIG_ENV_SECT_SIZE 0x1 /* size of one complete sector */
+#define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE -
CONFIG_ENV_SECT_SIZE)
+#define CONFIG_ENV_SIZE 0x4000 /* Total Size of Environment
Sector */
+/* Address and size of Redundant Environment Sector */
+#define CONFIG_ENV_ADDR_REDUND (CONFIG_ENV_ADDR -
CONFIG_ENV_SECT_SIZE)
+#define CONFIG_ENV_SIZE_REDUND (CONFIG_ENV_SIZE)
+#endif /* CONFIG_ENV_IS_IN_FLASH */
+/*
+ * NAND-FLASH related
+ */
+#if !defined(CONFIG_NAND_U_BOOT)
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+#define CONFIG_SYS_NAND_BASE \
+ (CONFIG_SYS_NAND_ADDR + CONFIG_SYS_NAND_CS)
+#define CONFIG_SYS_NAND_MAX_CHIPS 1
+#else /* NAND boot */
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+#define CONFIG_SYS_NAND_BASE \
+ {CONFIG_SYS_NAND0_ADDR + 0/*, CONFIG_SYS_NAND1_ADDR + 1*/}
+#define CONFIG_SYS_NAND_MAX_CHIPS 1
+#define NOT_USE_FLASH
+#endif
+/* nand driver supports mutipl. chips */
+#define CONFIG_SYS_NAND_SELECT_DEVICE 1
+/*
+ * Use 1 byte of I2C EEPROM as a flag to force SDRAM controller
+ * to be configured as 16-bit
+ */
+#define CONFIG_SDRAM_INFO_EEPROM_ADDR 0x54 /* Board specific */
+#define CONFIG_SDRAM16BIT_OFFSET 0x20 /* Board specific */
Those two defines are not used in your patches. Please remove.
+#if !defined(CONFIG_NAND_U_BOOT)
+/*
+ * NAND booting U-Boot version uses a fixed initialization, since the
whole + * I2C SPD DIMM autodetection/calibration doesn't fit into the 4k
of boot + * code.
+ */
+#define CONFIG_SPD_EEPROM 1 /* Use SPD EEPROM for setup */
+#define SPD_EEPROM_ADDRESS {0x53, 0x51} /* SPD i2c spd addresses */
+#define CONFIG_PPC4xx_DDR_AUTOCALIBRATION /* IBM DDR autocalibration
*/ +#define CONFIG_AUTOCALIB silent\0 /* default is non-verbose
*/ +#define CONFIG_DDR_ECC 1 /* with ECC support
*/
+#endif /* !defined(CONFIG_NAND_U_BOOT) */
+/*
+ * I2C
+ */
+#define CONFIG_SYS_I2C_SPEED 40 /* I2C speed */
+
+#define CONFIG_SYS_I2C_MULTI_EEPROMS
+#define CONFIG_SYS_I2C_EEPROM_ADDR (0xa81)
Space around .
+#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 3
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 5 /* Data sheet
*/
+/* I2C bootstrap EEPROM */
+#define CONFIG_4xx_CONFIG_I2C_EEPROM_ADDR 0x52
+#define CONFIG_4xx_CONFIG_I2C_EEPROM_OFFSET 0
+#define CONFIG_4xx_CONFIG_BLOCKSIZE 16
Those defines are used be the board specific chip_config command. Which you
didn't include in this patchset. Either add it or remove these defines.
+/*
+ * Ethernet
+ */
+#define CONFIG_IBM_EMAC4_V4 1
+#define CONFIG_EMAC_PHY_MODE EMAC_PHY_MODE_NONE_RGMII
+#define CONFIG_HAS_ETH0
+#define CONFIG_M88E_PHY
+/* PHY address, See schematics */
+#define CONFIG_PHY_ADDR 0x1f
+/* reset phy upon startup */
+#define CONFIG_PHY_RESET 1
+#define CONFIG_PHY_RESET_R
What's CONFIG_PHY_RESET_R? Please remove.
+/* Include GbE speed/duplex detection */
+#define CONFIG_PHY_GIGE 1
+#define CONFIG_PHY_DYNAMIC_ANEG 1
+/*
+ * External Bus Controller (EBC) Setup
+ **/
+#define CONFIG_SYS_EBC_CFG 0xB840 /* EBC0_CFG */
+
+#endif /* __CONFIG_H */
Please fix and resubmit. 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
--
Feng Kan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot-Users] U-boot for PPC405GP based custom Board
I dont know how the hardware is tied down. But at it seems to be getting bank 0 correctly. However, you second bank base address should be bank0_base + size instead of 0. You may have a hardware problem. Feng Kan On Thu, Jun 24, 2010 at 2:14 PM, ravi@rflelect.com wrote: Hi Feng, Below is the screen dump after enabling Debug. .. === Booting RFL GARD 8000 Controller using u-boot based bootloader === U-Boot 1.3.0-rc4 (Jun 24 2010 - 16:47:32) CPU: AMCC PowerPC 405GP Rev. E at 200 MHz (PLB=100, OPB=50, EBC=50 MHz) , PCI sync clock at 50 MHz 16 kB I-Cache 8 kB D-Cache Board: RFL-GARD8000 with AMCC PPC405GP processor I2C: ready DRAM: 64 MB SDRAM test passes FLASH: FLASH ADDR: fc00 FLASH MANUFACT: 10001 FLASH DEVICEID: 227e227e C2: LS: 22012201 info-flash_id: f2 Size of Flash0 at addr 0xfc00 is 0x200 FLASH ADDR: FLASH MANUFACT: ## Unknown FLASH on Bank 1 - Size = 0x = 0 MB Size of Flash1 at addr 0x0 is 0x0 32 MB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Error: start and/or end address not on sector boundary Error: start and/or end address not on sector boundary Error: start and/or end address not on sector boundary Hit any key to stop autoboot: 0 = flinfo Bank # 1: AMD S29GL256N (256 Mbit, uniform sector size) Size: 32768 KB in 256 Sectors Sector Start Addresses: FC00 FC02 FC04 FC06 FC08 FC0A FC0C FC0E FC10 FC12 FC14 FC16 FC18 FC1A FC1C FC1E FC20 FC22 FC24 FC26 FC28 FC2A FC2C FC2E FC30 FC32 FC34 FC36 FC38 FC3A FC3C FC3E FC40 FC42 FC44 FC46 FC48 FC4A FC4C FC4E FC50 FC52 FC54 FC56 FC58 FC5A FC5C FC5E FC60 FC62 FC64 FC66 FC68 FC6A FC6C FC6E FC70 FC72 FC74 FC76 FC78 FC7A FC7C FC7E FC80 FC82 FC84 FC86 FC88 FC8A FC8C FC8E FC90 FC92 FC94 FC96 FC98 FC9A FC9C FC9E FCA0 FCA2 FCA4 FCA6 FCA8 FCAA EFCAC FCAE EFCB0 FCB2 E FCB4 FCB6 EFCB8 FCBA EFCBC FCBE EFCC0 FCC2 EFCC4 FCC6 E FCC8 FCCA EFCCC FCCE EFCD0 FCD2 EFCD4 FCD6 EFCD8 FCDA FCDC FCDE EFCE0 FCE2 EFCE4 FCE6 EFCE8 FCEA EFCEC FCEE E FCF0 FCF2 EFCF4 FCF6 EFCF8 FCFA EFCFC FCFE EFD00 FD02 E FD04 FD06 FD08 FD0A EFD0C FD0E EFD10 FD12 EFD14 FD16 E FD18 FD1A EFD1C FD1E EFD20 FD22 EFD24 FD26 EFD28 FD2A E FD2C FD2E EFD30 FD32 EFD34 FD36 EFD38 FD3A FD3C FD3E E FD40 FD42 EFD44 FD46 EFD48 FD4A EFD4C FD4E EFD50 FD52 E FD54 FD56 EFD58 FD5A EFD5C FD5E EFD60 FD62 EFD64 FD66 FD68 FD6A EFD6C FD6E EFD70 FD72 EFD74 FD76 EFD78 FD7A E FD7C FD7E FD80 FD82 EFD84 FD86 EFD88 FD8A EFD8C FD8E E FD90 FD92 EFD94 FD96 EFD98 FD9A EFD9C FD9E EFDA0 FDA2 E FDA4 FDA6 EFDA8 FDAA FDAC FDAE EFDB0 FDB2 EFDB4 FDB6 E FDB8 FDBA EFDBC FDBE EFDC0 FDC2 EFDC4 FDC6 EFDC8 FDCA FDCC FDCE FDD0 FDD2 EFDD4 FDD6 EFDD8 FDDA EFDDC FDDE E FDE0 FDE2 EFDE4
Re: [U-Boot] 30-Second TFTP Timeout at Start-Up
Are you connected directly to the tftp server or is there switches in between?
Feng Kan
On 03/31/2010 01:09 PM, Jason Hanna wrote:
Hi All,
I'm seeing a strange TFTP issue and hoping someone on the list can help.
I'm running a Sequoia reference board and at start-up my TFTP transfer
always times out for 30 seconds, then proceeds without error or
further issue.
I ran Wireshark on my TFTP server, and also performed a port mirror of
the Sequoia board. I can confirm TFTP requests are only initiated 30
seconds after tftpboot is run.
Running with a static IP and the latest RC2 release of U-Boot. Boot
command is as follows:
net_nfs_fdt=tftp 20 ${bootfile};tftp ${fdt_addr} ${fdt_file};run
nfsargs addip addtty;bootm 20 - ${fdt_addr}
Startup log always looks the same...
U-Boot 2010.03-rc2-00011-gc0bf2cf-dirty (Mar 30 2010 - 20:10:06)
CPU: AMCC PowerPC 440EPx Rev. A at 666.667 MHz (PLB=166 OPB=83
EBC=55 PCI=83 MHz)
Security/Kasumi support
Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
Internal PCI arbiter enabled, PCI async ext clock used
32 kB I-Cache 32 kB D-Cache
Board: Sequoia - AMCC PPC440EPx Evaluation Board, Rev. F, PCI-Async=66 MHz
I2C: ready
DRAM: 256 MB
FLASH: 64 MB
NAND: 32 MiB
PCI: Bus Dev VenId DevId Class Int
USB: Host(int phy) Device(ext phy)
DTT: 1 is 38 C
Net: ppc_4xx_eth0, ppc_4xx_eth1
Type run net_nfs_fdt to load via TFTP and mount root via NFS
Hit any key to stop autoboot: 0
Waiting for PHY auto negotiation to complete... done
ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
Using ppc_4xx_eth0 device
TFTP from server X.X.X.X; our IP address is X.X.X.Y
Filename 'sequoia/uImage'.
Load address: 0x20
Loading: T T T T T T
#
done
Bytes transferred = 1528036 (1750e4 hex)
Using ppc_4xx_eth0 device
TFTP from server X.X.X.X; our IP address is X.X.X.Y
Filename 'sequoia/sequoia.dtb'.
Load address: 0x100
Loading: #
done
Bytes transferred = 8669 (21dd hex)
I think this has always been happening, even with older versions of
U-Boot. I finally got annoyed enough with this problem to dig a little
further.
:-)
Thanks,
-jmh
Jason Hanna
___
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] [PATCH 1/1] ppc4xx: add support for alternate format for ndfc
Hi Stefan: There is not a particular board that is stuck on this 213 format. Rather, for sometime u-boot and linux both had the 213 ordering. Lets say the guy did not have the SMC define turned on, which mean the ECC would caculate correctly for him. Now, he gets a new U-boot and want to update it. He gets to prompt and programs the new u-boot and linux (in 213 ordering). The new uboot comes up (it doesn't complain since there is no error message), runs to linux, the new linux expects 123 ordering. Finds ECC error and tries to correct and crash. I submitted this patch to support both ordering that the correction routine contains (123 and 213). Realistically, you can have any ordering you want (312 321) as long as the correction routine supports it. It is because of this reason, that the ndfc.c ordering keeps getting changed. I want the user to lock down the ordering they use. So they don't make the mistake of selecting SMC define but uses the 213 ordering (which would cause ecc errors). Cheers, Feng From: Stefan Roese [mailto:s...@denx.de] Sent: Mon 2/22/2010 2:52 AM To: Feng Kan Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/1] ppc4xx: add support for alternate format for ndfc Hi Feng, On Friday 19 February 2010 19:27:24 Feng Kan wrote: Agreed the ordering is working now. Previously the ordering is 213 and with CONFIG_MTD_NAND_ECC_SMC defined, wrong ECC error bit position was calculated. What about the boards that are now stuck on the 213 ordering. Which boards are stuck with this (incorrect) ordering? Please give an example. Also in linux, the ordering is not fixed down as in u-boot. I thought we had this fixed (or synced) in U-Boot *and* Linux. Hmm, perhaps that is another approach to the problem. Fix the ordering in linux? Again, I fail to see the problem here. Please give an example which board is failing here. 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
Re: [U-Boot] [PATCH 1/1] ppc4xx: add support for alternate format for ndfc
Dear Wolfgang: I will withdraw this patch. Feng From: Wolfgang Denk [mailto:w...@denx.de] Sent: Mon 2/22/2010 12:54 PM To: Feng Kan Cc: Stefan Roese; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/1] ppc4xx: add support for alternate format for ndfc Dear Feng Kan, In message 2b3b2aa816369a4e87d7be63ec9d2f260615a...@sdcexchange01.ad.amcc.com you wrote: There is not a particular board that is stuck on this 213 format. Rather, for sometime u-boot and linux both had the 213 ordering. Lets say the guy did not have the SMC define turned on, which mean the ECC would caculate correctly for him. Now, he gets a new U-boot and want to update it. He gets to prompt and programs the new u-boot and linux (in 213 ordering). The new uboot comes up (it doesn't complain since there is no error message), runs to linux, the new linux expects 123 ordering. Finds ECC error and tries to correct and crash. If this is your concern, then a compile-time setting makes little sense - you don't really expect that a user in this situation will build another U-Boot image after selecting other build options, install it (with the risk of bricking his device (keep in mind that not everybody has access to a JTAG debugger), and continue this so long until he finds a configuration that works for his combination of U-Boot and Linux settings. I submitted this patch to support both ordering that the correction routine contains (123 and 213). But it makes no sense as a compile time option. If you want to help users, then this must be implemented in a way that is selectable at run-time, for example by simple setting an 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 Everybody is talking about the weather but nobody does anything about it. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ppc4xx: add support for alternate format for ndfc
Hi Stefan: Agreed the ordering is working now. Previously the ordering is 213 and with CONFIG_MTD_NAND_ECC_SMC defined, wrong ECC error bit position was calculated. What about the boards that are now stuck on the 213 ordering. Also in linux, the ordering is not fixed down as in u-boot. Hmm, perhaps that is another approach to the problem. Fix the ordering in linux? Feng On 02/18/2010 11:57 PM, Stefan Roese wrote: Hi Feng, On Thursday 18 February 2010 23:25:13 f...@amcc.com wrote: From: Feng Kanf...@amcc.com This is to lock down the ordering in the correction routine against the calculate routine. Otherwise, incorrect define would cause ECC errors. It was my impression that we (finally) had done this ordering correct. The last changes were upon your request: 68e74567cf317318df52dbcb2ac170ffc5e7758a: ppc4xx: Fix ECC Correction bug with SMC ordering for NDFC driver I don't see how this patch should fix a potential problem. Please explain which problem exactly is fixed with this change. As Wolfgang already mentioned, CONFIG_MTD_NAND_ECC_SMC will not be set in this file. 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 1/1] ppc4xx: add support for alternate format for ndfc
Dear Wolfgang: The problem goes back a bit. The ordering you see in the ndfc file has been changed a few times, back and forth and cause quite a bit of problem. The define we speak of is in the driver/mtd/nand/nand_ecc.c file. The nand_correct_data function uses two ways of check ECC correctness. However the ndfc calculate only supports one ordering, although both placement method in the patch would work. It also serves to nail down the ordering depending on the define is used or not. There is also the following in the code, should you agree, this will also need to be removed as well. /* The PPC4xx NDFC uses Smart Media (SMC) bytes order */ #ifdef CONFIG_NAND_NDFC #define CONFIG_MTD_NAND_ECC_SMC #endif Feng Kan On 02/18/2010 03:13 PM, Wolfgang Denk wrote: Dear f...@amcc.com, In message1266531913-20756-1-git-send-email-f...@amcc.com you wrote: From: Feng Kanf...@amcc.com This is to lock down the ordering in the correction routine against the calculate routine. Otherwise, incorrect define would cause ECC errors. Signed-off-by: Feng Kanf...@amcc.com Acked-by: Victor Gallardovgalla...@amcc.com --- drivers/mtd/nand/ndfc.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c index 0dd6789..88e341d 100644 --- a/drivers/mtd/nand/ndfc.c +++ b/drivers/mtd/nand/ndfc.c @@ -89,9 +89,15 @@ static int ndfc_calculate_ecc(struct mtd_info *mtdinfo, /* The NDFC uses Smart Media (SMC) bytes order */ +#ifdef CONFIG_MTD_NAND_ECC_SMC ecc_code[0] = p[1]; ecc_code[1] = p[2]; ecc_code[2] = p[3]; +#else +ecc_code[0] = p[2]; +ecc_code[1] = p[1]; +ecc_code[2] = p[3]; +#endif This patch seems wrong to me as CONFIG_MTD_NAND_ECC_SMC is nowhere defined. [Also, it's not documented anywhere.] If this is fixing a bug, then please describe the exact problem, how to reproduce it, and how this patch is supposed to fix this problem. As is, this makes no sense to me. Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with transparent PCI-PCI bridge on Canyonlands
Can you turn on the additional debug information. That will give a better Clue as to what part is hanging. Feng Kan AMCC Software -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Felix Radensky Sent: Wednesday, December 09, 2009 10:02 AM To: u-boot@lists.denx.de; Stefan Roese Subject: [U-Boot] Problem with transparent PCI-PCI bridge on Canyonlands Hi, I'm running latest u-boot on 1GHz Canyonlands board and have trouble using 64-bit transparent PCI-PCI PLX 6254 bridge. With PLX evaluation board plugged into Canyonlands PCI slot u-boot hangs. With PCI support disabled u-boot works fine. The PLX board is OK, it was recognized by both u-boot and kernel on Freescale MPC8536DS board. On Canyonlands linux-2.6.32 silently resets the board when PLX is plugged in. Any ideas what could be wrong in u-boot ? I'll post a separate question to linuxppc-dev. U-Boot 2009.11-rc2-2-g386118a (Dec 09 2009 - 18:48:44) CPU: AMCC PowerPC 460EX Rev. A at 1000 MHz (PLB=200 OPB=100 EBC=100) Security/Kasumi support Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) Internal PCI arbiter enabled 32 kB I-Cache 32 kB D-Cache Board: Canyonlands - AMCC PPC460EX Evaluation Board, 2*PCIe, Rev. 14 I2C: ready DRAM: 512 MB (ECC not enabled, 400 MHz, CL3) FLASH: 64 MB NAND: 256 MiB PCI: Bus Dev VenId DevId Class Int Thanks a lot. Felix. ___ 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
[U-Boot] [PATCH 1/1] ppc4xx: Fix ECC Correction bug with SMC ordering for NDFC driver
Fix ECC Correction bug where the byte offset location were double flipped causing correction routine to toggle the wrong byte location in the ECC segment. The ndfc_calculate_ecc routine change the order of getting the ECC code. /* The NDFC uses Smart Media (SMC) bytes order */ ecc_code[0] = p[2]; ecc_code[1] = p[1]; ecc_code[2] = p[3]; But in the Correction algorithm when calculating the byte offset location, the s1 is used as the upper part of the address. Which again reverse the order making the final byte offset address location incorrect. byteoffs = (s1 0) 0x80; . . byteoffs |= (s0 4) 0x08; The order is change to read it in straight and let the correction function to revert it to SMC order. Signed-off-by: Feng Kan f...@amcc.com Acked-by: Victor Gallardo vgalla...@amcc.com Acked-by: Prodyut Hazarika phazar...@amcc.com --- drivers/mtd/nand/ndfc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c index 528b22b..0891936 100644 --- a/drivers/mtd/nand/ndfc.c +++ b/drivers/mtd/nand/ndfc.c @@ -89,8 +89,8 @@ static int ndfc_calculate_ecc(struct mtd_info *mtdinfo, /* The NDFC uses Smart Media (SMC) bytes order */ - ecc_code[0] = p[2]; - ecc_code[1] = p[1]; + ecc_code[0] = p[1]; + ecc_code[1] = p[2]; ecc_code[2] = p[3]; return 0; -- 1.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND ECC Error with wrong SMC ording bug
Hi Stefan: We had a board with high number of correctable ECC errors. Which crashed the jffs when it was miss correcting the wrong byte location. Do you want me to submit a patch for this, or do you prefer to do it. I am submitting a patch for linux right now. Feng Kan AMCC Software On 08/19/2009 10:01 PM, Stefan Roese wrote: On Thursday 20 August 2009 06:38:51 Sean MacLennan wrote: I see other boards using SMC as well, can someone comment on the change I am proposing. Should I change the correction algorithm or the calculate function? If the later is preferred it would mean the change must be pushed in both U-Boot and Linux. Odds are the calculate function is wrong. The correction algo is used by many nand drivers, I *assume* it is correct. The calculate function was set to agree with u-boot (1.3.0). Yes, it seems that you changed the order in the calculation function while reworking the NDFC driver for arch/powerpc. So we should probably change this order back to the original version. And change it in U-Boot as well. BTW: I didn't see any problems with ECC so far with the current code. Feng, how did you spot this problem? 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] NAND ECC Error with wrong SMC ording bug
Hi All:
It seems that the ECC correction is broken on the Linux with the 4xx
NDFC driver.
It uses the SMC order when reading the ECC code. 2-1-3
static int ndfc_calculate_ecc(struct mtd_info *mtd,
const u_char *dat, u_char *ecc_code)
{
struct ndfc_controller *ndfc = ndfc_ctrl;
uint32_t ecc;
uint8_t *p = (uint8_t *)ecc;
wmb();
ecc = in_be32(ndfc-ndfcbase + NDFC_ECC);
/* The NDFC uses Smart Media (SMC) bytes order */
ecc_code[0] = p[2];
ecc_code[1] = p[1];
ecc_code[2] = p[3];
return 0;
}
However, when in the correction function, the byte address order is
again reverses
causing incorrect byte location.
* performace it does not make any difference
*/
if (eccsize_mult == 1)
byte_addr = (addressbits[b0] 4) +
addressbits[b1];
The above really should be byte_addr = (addressbits[b1] 4) +
addressbits[b0];
else
byte_addr = (addressbits[b2 0x3] 8) +
(addressbits[b1] 4) +
addressbits[b0];
bit_addr = addressbits[b2 2];
/* flip the bit */
buf[byte_addr] ^= (1 bit_addr);
printk(KERN_INFO Corrected b[0] 0x%x b[1]0x%x\n, b0, b1);
printk(KERN_INFO cal ecc b[0] 0x%x b[1]0x%x\n,
calc_ecc[0] , calc_ecc[1]);
printk(KERN_INFO read ecc b[0] 0x%x b[1]0x%x\n,
read_ecc[0] , read_ecc[1]);
return 1;
I see other boards using SMC as well, can someone comment on the change
I am proposing.
Should I change the correction algorithm or the calculate function? If
the later is preferred
it would mean the change must be pushed in both U-Boot and Linux.
Feng Kan
AMCC Software
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot compile error
Hi Afzal: Would you please send me the link to the files you got. I can help you check it out. Feng Kan AMCC Software Engineering -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Afzal Nadirshah Sent: Thursday, February 05, 2009 9:13 PM To: u-boot@lists.denx.de Subject: [U-Boot] U-Boot compile error Hi, I had downloaded U-Boot source code from AMCC website to build a u-boot image for NAND Flash. Inside the u-boot directory I executed the following commands: make distclean make canyonlands_nand_config But I get the following error : : invalid option make: *** [canyonlands_nand_config] Error 1 These same commands executed inside the u-boot downloaded from the DENX site, does not give any errors. Has anybody else such a problem? Regards, Afzal Nadirshah http://www.mindtree.com/email/disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Hanging
Hi Afzal: Sounds like an issue where the fixed DRAM init did not work as it should. Try to pull the latest version of U-Boot, see if that helps. You may want to pull The latest from Stefan's tree as well. Feng Kan AMCC Software -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Afzal Nadirshah Sent: Tuesday, February 03, 2009 2:02 AM To: u-boot@lists.denx.de Subject: [U-Boot] U-Boot Hanging Hi, I have compiled u-boot (for nand flash, using canyonlands_nand_config) for the canyonlands board having a PPC460Ex. I have flashed the u-boot-nand.bin to the NAND flash. When I boot from the NAND flash the u-boot starts giving outputs onto minicom, but it hangs after just a few statements. U-Boot 1.3.4-00380-g302e52e (Sep 8 2008 - 15:37:41) CPU: AMCC PowerPC 460EX Rev. A at 600 MHz (PLB=200, OPB=100, EBC=100 MHz) Security/Kasumi support Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) Internal PCI arbiter disabled 32 kB I-Cache 32 kB D-Cache Board: Canyonlands - AMCC PPC460EX Evaluation Board, 2*PCIe, Rev. 16 I2C: ready DTT: 1 is 47 C DRAM: 512 MB Has anybody faced this issue? Regards, Afzal Nadirshah http://www.mindtree.com/email/disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Add tlbentry problem]
Hi Yshim: Please check your EBC CR value, if you configure for 2M, then thats what you will get. Feng Kan 김영순 wrote: I’ve worked on my custum board based on SEQUOIA. I’d like to add new device (DSP, SIZE=256M, CS4). I added tlbentry(256M) in init.S and defined CS4 in sequoia.h. Init.S: /* TLB-entry for EBC(DSP) */ tlbentry( CFG_DSP_BASE, SZ_256M, CFG_DSP_BASE, 1, AC_R|AC_W|AC_X|SA_G|SA_I ) sequoia.h: #define CFG_DSP_BASE 0xd000 #define CFG_EBC_PB4AP 0x05014300 #define CFG_EBC_PB4CR (CFG_DSP_BASE | 0x3a000) The problem is this. When I access over 2Mbytes area of DSP4(Over d020), I’ve got bus error in my application. Accessing to under 2Mbytes, it works well…. Are there anything to do, when I want to attatch new devices Best Regards… ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ppc4xx: fix UIC hang if critical or non-critical interrupt is set at the same time as a normal interrupt is set on UIC0
Hi Wolfgang: I send the patch out for Victor. In the original email the From field did indicate his name. Am I missing something? Thanks Feng Kan Dear [EMAIL PROTECTED], Can you please provide a real name with your mail address when submitting patches? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
