Re: [U-Boot] TFTP on beagle board
Mai Daftedar wrote: > Hi all, >I was wondering how can we configure the u-boot with the TFTP > capability on the beagle board at runtime.. For this you will need ethernet support in U-Boot. There are two (?) options to achieve this: Add support for USB ethernet dongle in U-Boot or use a Beagle expansion card with ethernet. Regarding USB ethernet dongle, there are some basic USB patches for Beagle U-Boot on the list. But I'm not sure how much work it is to enable them to support USB ethernet. For ethernet on expansion board, there is TinCanTool's Zippy board [1]. To access ethernet on this board from U-Boot, an U-Boot OMAP3 SPI driver is missing. Both options are not ready, yet, and need some development work. Any help is greatly appreciated! Cheers Dirk Btw.: I added U-Boot list, it is the better place to discuss this. [1] http://www.tincantools.com/product.php?productid=16147&cat=0&page=1&featured ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] fec_imx27: driver for FEC ethernet controller on i.MX27
Dear Alfred Steele, In message <528f13590911161846q6a91df8awa309d4e1f990d...@mail.gmail.com> you wrote: > > Thanks for your submission! > What is the current design on the mxc fec interface's attainment of a > MAC address. From the kernel driver it looks like it looks at the There is none. > IIM(IC identification registers) on the MXC platform(like mx51/35) to > look for a programmed mac address and then the set the fec mac to the > same . > > Looks like with the current mxc_fec driver there is not support for > the same. I am thinking of a mechanism to hardcode a fake MAC which > would subsequently be picked up by the kernel without using the > bd_info structure. You must not do this. First, you must not use any "fake" addresses at all (especially not since the board most probably has a real one in the environment). Second, read the FAQ (http://www.denx.de/wiki/view/DULG/EthernetDoesNotWorkInLinux). 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 ATTENTION: Despite Any Other Listing of Product Contents Found Here- on, the Consumer is Advised That, in Actuality, This Product Consists Of 99.99% Empty Space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] crc32: Impl. linux optimized crc32()
On Monday 16 November 2009 23:01:59 Mike Frysinger wrote: > On Friday 13 November 2009 03:52:05 Joakim Tjernlund wrote: > > --- a/lib_generic/crc32.c > > +++ b/lib_generic/crc32.c > > @@ -13,6 +13,8 @@ > > #else > > #include > > #endif > > +#include > > +#include > > the target system improvements are awesome, but this breaks cross-compiling > crc32 code for anything other than linux hosts (and even that is spotty). > > i'd suggest these changes > > @@ -10,10 +10,10 @@ > > #ifndef USE_HOSTCC /* Shut down "ANSI does not permit..." warnings */ > #include > +#include > #else > -#include > +#include > #endif > -#include > #include actually, now that i re-read what i put into compiler.h, even this header logic is more complex than it needs to be. you should be able to have it simply read #include #include -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] crc32: Impl. linux optimized crc32()
On Friday 13 November 2009 03:52:05 Joakim Tjernlund wrote:
> --- a/lib_generic/crc32.c
> +++ b/lib_generic/crc32.c
> @@ -13,6 +13,8 @@
> #else
> #include
> #endif
> +#include
> +#include
the target system improvements are awesome, but this breaks cross-compiling
crc32 code for anything other than linux hosts (and even that is spotty).
i'd suggest these changes
@@ -10,10 +10,10 @@
#ifndef USE_HOSTCC /* Shut down "ANSI does not permit..." warnings */
#include
+#include
#else
-#include
+#include
#endif
-#include
#include
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
@@ -24,6 +24,8 @@
#define local static
#define ZEXPORT/* empty */
+#define tole(x) cpu_to_le32(x)
+
#ifdef DYNAMIC_CRC_TABLE
local int crc_table_empty = 1;
@@ -54,7 +56,6 @@ local void make_crc_table OF((void));
the information needed to generate CRC's on data a byte at a time for all
combinations of CRC register values and incoming bytes.
*/
-#define tole(x) __cpu_to_le32(x)
local void make_crc_table()
{
uint32_t c;
@@ -81,7 +82,6 @@ local void make_crc_table()
/*
* Table of CRC-32's of all single-byte values (made by make_crc_table)
*/
-#define tole(x) __constant_cpu_to_le32(x)
local const uint32_t crc_table[256] = {
tole(0xL), tole(0x77073096L), tole(0xee0e612cL), tole(0x990951baL),
@@ -185,7 +185,7 @@ uint32_t ZEXPORT crc32_no_comp(uint32_t crc, const Bytef
*buf, uInt len)
if (crc_table_empty)
make_crc_table();
#endif
-crc = __cpu_to_le32(crc);
+crc = cpu_to_le32(crc);
/* Align it */
if (((long)b) & 3 && len) {
uint8_t *p = (uint8_t *)b;
@@ -214,7 +214,7 @@ uint32_t ZEXPORT crc32_no_comp(uint32_t crc, const Bytef
*buf, uInt len)
} while (--len);
}
-return __le32_to_cpu(crc);
+return le32_to_cpu(crc);
}
#undef DO_CRC
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] fec_imx27: driver for FEC ethernet controller on i.MX27
Hi Alfred, alfred steele wrote: >> Thanks for your submission! >> > What is the current design on the mxc fec interface's attainment of a > MAC address. From the kernel driver it looks like it looks at the > IIM(IC identification registers) on the MXC platform(like mx51/35) to > look for a programmed mac address and then the set the fec mac to the > same . > > Looks like with the current mxc_fec driver there is not support for > the same. I am thinking of a mechanism to hardcode a fake MAC which > would subsequently be picked up by the kernel without using the > bd_info structure. > Any comments/suggestions? > > -Alfred. > I don't know much about this driver, but it appears to be doing things incorrectly. The correct flow is as follows. It is documented in 'doc/README.enetaddr': 1. The driver's initialize() function read from NVRAM if available. MAC address is stuffed into dev->enetaddr. The initialize() function should not try to get the address from the environment, which is where the imx27 driver goes wrong. 2. After all drivers have been initialized, eth_initialize() ( in net/eth.c) reads from the environment. If the value in the environment is valid and the value in dev->enetaddr is valid and both are different, the user is warned. The value in the environment overwrites the value in dev->enetaddr 3. When a network operation is performed, the driver's init() function is called, which is where the address is programmed into the device. As you can see, if the device is never used, step 3 is never exected and the device is never programmed. This is how it's supposed to work, since the U-boot design philosophy dictates that hardware is never touched unless it is used in U-boot. I'm pretty sure hard-coding a fake MAC address would run afoul of this rule. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] fec_imx27: driver for FEC ethernet controller on i.MX27
> Thanks for your submission! What is the current design on the mxc fec interface's attainment of a MAC address. From the kernel driver it looks like it looks at the IIM(IC identification registers) on the MXC platform(like mx51/35) to look for a programmed mac address and then the set the fec mac to the same . Looks like with the current mxc_fec driver there is not support for the same. I am thinking of a mechanism to hardcode a fake MAC which would subsequently be picked up by the kernel without using the bd_info structure. Any comments/suggestions? -Alfred. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] env: Group environment variables
Dear John Schmoller, In message <1257460973.8937.1170.ca...@johns> you wrote: > > > > > Also, it would be nice if "prontenv" now would allow to print a group, > > > > i. e. in your example something as "printenv net pci" should be > > > > supported. > > > > > > This is already (accidentally :) supported. a "printenv $net" would do > > > just what you state. > > > > Um.. this is not what I mean. > > So, a "printenv net" would print > ipaddr netmask gatewayip serverip > > A "printenv $net" would print > ipaddr=10.52.0.133 > netmask=255.255.0.0 > gatewayip=10.52.0.1 > serverip=10.52.0.33 > > Do you mean something other than either of those? Please ignore my question. My brain was offline when I asked this one. You are right, of course. 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 wrote my name at the top of the page. I wrote down the number of the question ``1''. After much reflection I put a bracket round it thus ``(1)''. But thereafter I could not think of anything connected with it that was either relevant or true. - Sir Winston Churchill _My Early Life_ ch. 2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ARM Add New Board GEC2410
Dear "Hui.Tang", In message <1257324505-19451-1-git-send-email-zetal...@gmail.com> you wrote: > S3C2410 NAND flash add missing function. Please squash into one single NAND flash related 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 A Chairman was as necessary to a Board planet as the zero was in mathematics, but being a zero had big disadvantages... - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] ARM Add New Board GEC2410
Dear "Hui.Tang", In message <1257324383-19408-1-git-send-email-zetal...@gmail.com> you wrote: > Add ARM920T NAND flash booting. > > checkpatch.pl shows that all things are fine. > > total: 0 errors, 0 warnings, 70 lines checked > > 0002-ARM920T-NAND-flash-booting.patch has no obvious style problems and is > ready for submission. > > = > Signed-off-by: Hui.Tang > --- > cpu/arm920t/start.S | 20 > 1 files changed, 20 insertions(+), 0 deletions(-) > > diff --git a/cpu/arm920t/start.S b/cpu/arm920t/start.S > index 114427a..9b08e3c 100644 > --- a/cpu/arm920t/start.S > +++ b/cpu/arm920t/start.S > @@ -38,6 +38,7 @@ > > .globl _start > _start: b start_code > +#ifndef CONFIG_NAND_SPL > ldr pc, _undefined_instruction > ldr pc, _software_interrupt > ldr pc, _prefetch_abort > @@ -53,7 +54,13 @@ _data_abort: .word data_abort > _not_used: .word not_used > _irq:.word irq > _fiq:.word fiq > +_pad:.word 0x12345678 /* now 16*4=64 */ > +#else > + . = _start + 64 > +#endif As there is no code added to ever set CONFIG_NAND_SPL, all this is just dead code - or an incomplete patch. Please make sure to split your patches such that they are really orthogonal to each other. Don't add some parts of CONFIG_NAND_SPL stuff in one patch and some other parts in another one. > _start_armboot: .word start_armboot > +#else > + b nand_boot > +/* .word nand_boot */ Don't add dead code. 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 use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM Add New Board GEC2410
Dear "Hui.Tang",
In message <1257324286-19359-1-git-send-email-zetal...@gmail.com> you wrote:
> This patch add a new ARM board GEC2410.
> checkpatch.pl shows that all things are fine.
>
> total: 0 errors, 0 warnings, 1268 lines checked
>
> 0001-ARM-Add-New-Board-GEC2410.patch has no obvious style problems and is
> ready for submission.
As mentioned before by others: this does noty belong into tht ecommit
message.
> diff --git a/Makefile b/Makefile
> index bcb3fe9..2de0b1d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2951,6 +2951,13 @@ davinci_dm365evm_config : unconfig
> davinci_dm6467evm_config : unconfig
> @$(MKCONFIG) $(@:_config=) arm arm926ejs dm6467evm davinci davinci
>
> +gec2410_config : unconfig
> + @mkdir -p $(obj)include $(obj)board/gec/gec2410
> + @mkdir -p $(obj)nand_spl/board/gec/gec2410
> + @echo "RAM_TEXT = 0x33e0" >> $(obj)board/gec/gec2410/config.tmp
> + @$(MKCONFIG) $(@:_config=) arm arm920t gec2410 gec s3c24x0
> + @echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk
Please so not put such scripting into the top level Makefile.
Especially since this is all unconditional. Please move to board
config file.
> diff --git a/board/gec/gec2410/config.mk b/board/gec/gec2410/config.mk
> new file mode 100644
> index 000..f32ee2e
> --- /dev/null
> +++ b/board/gec/gec2410/config.mk
...
> +sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp
> +
> +ifndef CONFIG_NAND_SPL
> +TEXT_BASE = $(RAM_TEXT)
> +else
> +TEXT_BASE = 0
> +endif
There is nothing in the code that would set CONFIG_NAND_SPL, so please
get rid of the dead code.
> +LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot-nand.lds
u-boot-nand.lds? Sure?
> +PLATFORM_CPPFLAGS += -I$(TOPDIR)/board/gec/gec2410
Why is this needed?
> diff --git a/board/gec/gec2410/gec2410.c b/board/gec/gec2410/gec2410.c
> new file mode 100644
> index 000..a9b6290
> --- /dev/null
> +++ b/board/gec/gec2410/gec2410.c
> @@ -0,0 +1,313 @@
...
> +#define FCLK_SPEED 1
> +
> +#if FCLK_SPEED == 0 /* Fout = 203MHz, Fin = 12MHz for Audio */
> +#define M_MDIV 0xC3
> +#define M_PDIV 0x4
> +#define M_SDIV 0x1
> +#elif FCLK_SPEED == 1/* Fout = 202.8MHz */
> +#define M_MDIV 0xA1
> +#define M_PDIV 0x3
> +#define M_SDIV 0x1
> +#endif
> +
> +#define USB_CLOCK 1
> +
> +#if USB_CLOCK == 0
> +#define U_M_MDIV 0xA1
> +#define U_M_PDIV 0x3
> +#define U_M_SDIV 0x1
> +#elif USB_CLOCK == 1
> +#define U_M_MDIV 0x48
> +#define U_M_PDIV 0x3
> +#define U_M_SDIV 0x2
> +#endif
Please move to some header file.
> +static inline void delay(unsigned long loops)
> +{
> + __asm__ volatile ("1:\n"
> + "subs %0, %1, #1\n"
> + "bne 1b" : "=r" (loops) : "0" (loops));
> +}
Is there really no better way to implement a delay? For example in a
way that does not depend on the system clock?
> --- a/cpu/arm920t/s3c24x0/timer.c
> +++ b/cpu/arm920t/s3c24x0/timer.c
> @@ -188,7 +188,8 @@ ulong get_tbclk(void)
> tbclk = timer_load_val * 100;
> #elif defined(CONFIG_SBC2410X) || \
>defined(CONFIG_SMDK2410) || \
> - defined(CONFIG_VCMA9)
> + defined(CONFIG_VCMA9) || \
> + defined(CONFIG_GEC2410)
> tbclk = CONFIG_SYS_HZ;
Please keep list sorted.
And maybe we can use a feature-specific define instead of adding more
and more boards here?
> diff --git a/include/configs/gec2410.h b/include/configs/gec2410.h
> new file mode 100644
> index 000..8279e36
> --- /dev/null
> +++ b/include/configs/gec2410.h
> @@ -0,0 +1,262 @@
...
> +#if 0
> +#undef CONFIG_USE_IRQ/* we don't need IRQ/FIQ stuff
> */
> +
> +#undef CONFIG_SKIP_RELOCATE_UBOOT
> +#endif
Please do not add dead code.
> +#include
> +
> +#define CONFIG_CMD_CACHE
> +#define CONFIG_CMD_SAVEENV
> +#define CONFIG_CMD_NAND
> +#define CONFIG_CMD_PING
> +#define CONFIG_CMD_ELF
> +#define CONFIG_CMD_FAT
You may want to keep such lists sorted.
> diff --git a/nand_spl/board/gec/gec2410/u-boot.lds
> b/nand_spl/board/gec/gec2410/u-boot.lds
> new file mode 100644
> index 000..5871f7e
> --- /dev/null
> +++ b/nand_spl/board/gec/gec2410/u-boot.lds
This file seems to be unused. Why add it?
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
"A verbal contract isn't worth the paper it's printed on."
- Samuel Goldwyn
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] [OneNAND] Flex-OneNAND boundary settings
Dear Amul Kumar Saha, In message <0870c11eae73409e8727cac3891e4...@sisodomain.com> you wrote: > Add command for changing Flex-OneNAND SLC / MLC boundary. > Also onenand commands work for Flex-OneNAND. > > Signed-off-by: Rohit Hagargundgi > Signed-off-by: Amul Kumar Saha > --- > common/cmd_onenand.c | 106 > +++--- > include/configs/apollon.h |2 > 2 files changed, 74 insertions(+), 34 deletions(-) How many versions of these patches did you post so far? You are supposed to use "[PATCH 3/3 v5]" or similar in the Subject: line to mark the Nth re-submission of the patch. And what was changed between versions of this patch? You are supposed to put a change log below the "---" line that explains which changes were made to the previous version of the 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 "Never give in. Never give in. Never. Never. Never." - Winston Churchill ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] flash.h: pull in common.h for types
On Monday 16 November 2009 16:31:27 Wolfgang Denk wrote: > Mike Frysinger wrote: > > Signed-off-by: Mike Frysinger > > --- > > include/flash.h |3 +++ > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > diff --git a/include/flash.h b/include/flash.h > > index c5e7bf4..886d8ef 100644 > > --- a/include/flash.h > > +++ b/include/flash.h > > @@ -25,6 +25,9 @@ > > #define _FLASH_H_ > > > > #ifndef CONFIG_SYS_NO_FLASH > > + > > +#include > > + > > Why would that be needed? Which problem are you trying to solve? like the subject very briefly says, 'for types'. if your source code includes flash.h before anything else, it'll fail to compile as flash.h uses types not declared implicitly by the compiler. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] flash.h: pull in common.h for types
Dear Mike Frysinger, In message <1258401513-16014-1-git-send-email-vap...@gentoo.org> you wrote: > Signed-off-by: Mike Frysinger > --- > include/flash.h |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/include/flash.h b/include/flash.h > index c5e7bf4..886d8ef 100644 > --- a/include/flash.h > +++ b/include/flash.h > @@ -25,6 +25,9 @@ > #define _FLASH_H_ > > #ifndef CONFIG_SYS_NO_FLASH > + > +#include > + Why would that be needed? Which problem are you trying to solve? 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 Always leave room to add an explanation if it doesn't work out. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] OMAP3: add CM-T35 board
Mike Rapoport wrote: > >>> >>> >> Yes this change would apply to all the omap3 boards. >> But it looks like they are are all the same change. >> >> The change per board, would be to delete these externs once the >> first code change is made. >> >> Since this is a code movement change, it can be verified by running >> MAKEALL arm before and after the change. > > The problem here, that just moving these externs to e.g. > include/arm-arm/arch-omap3/mem.h is not enough. All omap3 boards set > environment > related defines to these externs, and therefore without them common/env_nand > does not build. It seems that all the board_flash_* variables can be > completely > removed completely, but I really don't know what was the original author > intention about those variables. > I have posted a patch for the first part of this problem with gpmc. I am testing a change now to remove the board_flash_* variables. After that I think we will be ok. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP3 Move declaration of gpmc_cfg.
Every omap3 board config file declared the global variable gpmc_cfg.
This changes moves the declaration to a better location in the
arch dependent header file cpu.h.
Signed-off-by: Tom Rix
---
include/asm-arm/arch-omap3/cpu.h |4
include/configs/devkit8000.h |1 -
include/configs/omap3_beagle.h |1 -
include/configs/omap3_evm.h |1 -
include/configs/omap3_overo.h|1 -
include/configs/omap3_pandora.h |1 -
include/configs/omap3_sdp3430.h |1 -
include/configs/omap3_zoom1.h|1 -
include/configs/omap3_zoom2.h|1 -
9 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/include/asm-arm/arch-omap3/cpu.h b/include/asm-arm/arch-omap3/cpu.h
index e51c4f3..aa8de32 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -136,6 +136,10 @@ struct gpmc {
u32 ecc8_result;/* 0x21C */
u32 ecc9_result;/* 0x220 */
};
+
+/* Used for board specific gpmc initialization */
+extern struct gpmc *gpmc_cfg;
+
#else /* __ASSEMBLY__ */
#define GPMC_CONFIG1 0x00
#define GPMC_CONFIG2 0x04
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index 1011770..7487bb7 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -299,7 +299,6 @@
#define CONFIG_ENV_OFFSET boot_flash_off
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 024b9b8..70186ce 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -314,7 +314,6 @@
#define CONFIG_SYS_JFFS2_NUM_BANKS 1
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 6709edc..162bfea 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -295,7 +295,6 @@
#define CONFIG_SYS_JFFS2_NUM_BANKS 1
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 0f812a7..ff25aba 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -299,7 +299,6 @@
#define CONFIG_SYS_JFFS2_NUM_BANKS 1
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h
index 0cafeb8..838b1ad 100644
--- a/include/configs/omap3_pandora.h
+++ b/include/configs/omap3_pandora.h
@@ -292,7 +292,6 @@
#define CONFIG_SYS_JFFS2_NUM_BANKS 1
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_sdp3430.h b/include/configs/omap3_sdp3430.h
index d91c8ff..a2a4b8a 100644
--- a/include/configs/omap3_sdp3430.h
+++ b/include/configs/omap3_sdp3430.h
@@ -361,7 +361,6 @@
/*--*/
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h
index 2aef973..62a6340 100644
--- a/include/configs/omap3_zoom1.h
+++ b/include/configs/omap3_zoom1.h
@@ -300,7 +300,6 @@
#define CONFIG_SYS_JFFS2_NUM_BANKS 1
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_zoom2.h b/include/configs/omap3_zoom2.h
index 5b03fb6..5296630 100644
--- a/include/configs/omap3_zoom2.h
+++ b/include/configs/omap3_zoom2.h
@@ -255,7 +255,6 @@
#define CONFIG_SYS_FLASH_WRITE_TOUT(100 * CONFIG_SYS_HZ)
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP3 move declaration of gpmc_cfg
This is cleanup of omap3 board config files. This is the link to the thread on the list http://lists.denx.de/pipermail/u-boot/2009-November/064351.html This was regression tested with MAKEALL arm and runtested on Zoom2 Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] flash.h: pull in common.h for types
Signed-off-by: Mike Frysinger --- include/flash.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/flash.h b/include/flash.h index c5e7bf4..886d8ef 100644 --- a/include/flash.h +++ b/include/flash.h @@ -25,6 +25,9 @@ #define _FLASH_H_ #ifndef CONFIG_SYS_NO_FLASH + +#include + /*--- * FLASH Info: contains chip specific data, per FLASH bank */ -- 1.6.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Davinci: Configurable NAND chip selects
Hi Nick,
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Nick Thompson
> Sent: Monday, November 16, 2009 12:50 PM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH] Davinci: Configurable NAND chip selects
>
> Davinci: Configurable NAND chip selects
>
> Add a CONFIG_SYS_NAND_CS setting to all davinci configs and
> use it to setup the NAND controller in the davinci_nand
> mtd driver.
>
> Signed-off-by: Nick Thompson
> ---
> This config item is already used on many other platforms
> so is not a new config item as such.
>
> This change should not result in any functional changes to
> current davinci boards. They all seem to use CS2 as this
> was the only chip select supported by the driver. da830evm
> however uses CS3, so a configurable driver is required.
My testing branch has all the NAND updates. I'll add this and test it out. I
don't expect to see any issues though.
>
> Applies to: u-boot-ti
>
> drivers/mtd/nand/davinci_nand.c | 16 ++--
> include/asm-arm/arch-davinci/emif_defs.h |9 +
> include/configs/davinci_dm355evm.h |1 +
> include/configs/davinci_dm355leopard.h |1 +
> include/configs/davinci_dm365evm.h |1 +
> include/configs/davinci_dm6467evm.h |1 +
> include/configs/davinci_dvevm.h |1 +
> include/configs/davinci_schmoogie.h |1 +
> include/configs/davinci_sffsdr.h |1 +
> include/configs/davinci_sonata.h |1 +
> 10 files changed, 27 insertions(+), 6 deletions(-)
OK but I don't see a change to the DA830 config which was the reason for the
patch in the first place.
>
> diff --git a/drivers/mtd/nand/davinci_nand.c
> b/drivers/mtd/nand/davinci_nand.c
> index eabaf3e..1900a1a 100644
> --- a/drivers/mtd/nand/davinci_nand.c
> +++ b/drivers/mtd/nand/davinci_nand.c
> @@ -82,12 +82,13 @@ static void nand_davinci_hwcontrol(struct mtd_info
> *mtd, int cmd, unsigned int c
>
> static void nand_davinci_enable_hwecc(struct mtd_info *mtd, int mode)
> {
> - int dummy;
> + u_int32_t val;
>
> - dummy = emif_regs->NANDF1ECC;
> + val = readl(&emif_regs->NANDF1ECC);
>
> - /* FIXME: only chipselect 0 is supported for now */
> - emif_regs->NANDFCR |= 1 << 8;
> + val = readl(&emif_regs->NANDFCR);
> + val |= DAVINCI_NANDFCR_1BIT_ECC_START(CONFIG_SYS_NAND_CS);
> + writel(val, &emif_regs->NANDFCR);
> }
>
> static u_int32_t nand_davinci_readecc(struct mtd_info *mtd, u_int32_t
> region)
> @@ -214,8 +215,11 @@ static void nand_davinci_4bit_enable_hwecc(struct
> mtd_info *mtd, int mode)
>* Start a new ECC calculation for reading or writing 512
> bytes
>* of data.
>*/
> - val = (emif_regs->NANDFCR & ~(3 << 4)) | (1 << 12);
> - emif_regs->NANDFCR = val;
> + val = readl(&emif_regs->NANDFCR);
> + val &= ~DAVINCI_NANDFCR_4BIT_ECC_SEL_MASK;
> + val |= DAVINCI_NANDFCR_4BIT_ECC_SEL(CONFIG_SYS_NAND_CS);
> + val |= DAVINCI_NANDFCR_4BIT_ECC_START;
> + writel(val, &emif_regs->NANDFCR);
> break;
> case NAND_ECC_READSYN:
> val = emif_regs->NAND4BITECC1;
> diff --git a/include/asm-arm/arch-davinci/emif_defs.h b/include/asm-
> arm/arch-davinci/emif_defs.h
> index c91e30c..5a36ece 100644
> --- a/include/asm-arm/arch-davinci/emif_defs.h
> +++ b/include/asm-arm/arch-davinci/emif_defs.h
> @@ -68,4 +68,13 @@ typedef struct {
> } emif_registers;
>
> typedef emif_registers *emifregs;
> +
> +#define DAVINCI_NANDFCR_4BIT_ECC_SEL_MASK(3 << 4)
> +#define DAVINCI_NANDFCR_4BIT_ECC_SEL(n) ((n-2) << 4)
> +
> +#define DAVINCI_NANDFCR_1BIT_ECC_START(n)(1 << (8 + (n-2)))
> +
> +#define DAVINCI_NANDFCR_4BIT_ECC_START (1 << 12)
> +#define DAVINCI_NANDFCR_4BIT_CALC_START (1 << 13)
> +
> #endif
> diff --git a/include/configs/davinci_dm355evm.h
> b/include/configs/davinci_dm355evm.h
> index ea40df0..07914a3 100644
> --- a/include/configs/davinci_dm355evm.h
> +++ b/include/configs/davinci_dm355evm.h
> @@ -66,6 +66,7 @@
>
> /* NAND: socketed, two chipselects, normally 2 GBytes */
> #define CONFIG_NAND_DAVINCI
> +#define CONFIG_SYS_NAND_CS 2
> #define CONFIG_SYS_NAND_USE_FLASH_BBT
> #define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
> #define CONFIG_SYS_NAND_PAGE_2K
> diff --git a/include/configs/davinci_dm355leopard.h
> b/include/configs/davinci_dm355leopard.h
> index 5db720e..54b153d 100644
> --- a/include/configs/davinci_dm355leopard.h
> +++ b/include/configs/davinci_dm355leopard.h
> @@ -65,6 +65,7 @@
>
> /* NAND */
> #define CONFIG_NAND_DAVINCI
> +#define CONFIG_SYS_NAND_CS 2
> #define CONFIG_SYS_NAND_USE_FLASH_BBT
> #define CONFIG_SYS_NAND_HW_ECC
>
> diff --git a/include/configs/davinci_dm365evm.h
> b/include/configs
[U-Boot] [PATCH] NAND: Update read_read_subpage API check
From: Sandeep Paulraj This patch updates a check condition in the NAND driver. The check condition is similat to what is in linux/next. Signed-off-by: Sandeep Paulraj --- drivers/mtd/nand/nand_base.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 6da261c..7171bdd 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -1061,7 +1061,7 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip, uint3 int stat; stat = chip->ecc.correct(mtd, p, &chip->buffers->ecccode[i], &chip->buffers->ecccalc[i]); - if (stat < 0) + if (stat == -1) mtd->ecc_stats.failed++; else mtd->ecc_stats.corrected += stat; -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] NAND:Extending the nand_ecclayout structure
From: Sandeep Paulraj
NANDs with page size of lesser than and equal to 2K are
reaching EOL. They are bing replaced with NANDs of
page size 4K and above.
To support this we have to extend the eccpos field
Signed-off-by: Sandeep Paulraj
---
I believe a patch was submitted to linux-mtd to update this.
But this change was rejected to the best of my knowledge because
it will break user space IOCTL's, i.e. when we we run some tests
from the mtd-utils. I can't see an solution to the issue addressed
in the kernel or mtd-utils. I think this can be added to u-boot.
include/linux/mtd/mtd-abi.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/mtd/mtd-abi.h b/include/linux/mtd/mtd-abi.h
index 410c5dd..8d5f60c 100644
--- a/include/linux/mtd/mtd-abi.h
+++ b/include/linux/mtd/mtd-abi.h
@@ -123,7 +123,7 @@ struct nand_oobfree {
*/
struct nand_ecclayout {
uint32_t eccbytes;
- uint32_t eccpos[64];
+ uint32_t eccpos[128];
uint32_t oobavail;
struct nand_oobfree oobfree[MTD_MAX_OOBFREE_ENTRIES];
};
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Davinci: Configurable NAND chip selects
Davinci: Configurable NAND chip selects
Add a CONFIG_SYS_NAND_CS setting to all davinci configs and
use it to setup the NAND controller in the davinci_nand
mtd driver.
Signed-off-by: Nick Thompson
---
This config item is already used on many other platforms
so is not a new config item as such.
This change should not result in any functional changes to
current davinci boards. They all seem to use CS2 as this
was the only chip select supported by the driver. da830evm
however uses CS3, so a configurable driver is required.
Applies to: u-boot-ti
drivers/mtd/nand/davinci_nand.c | 16 ++--
include/asm-arm/arch-davinci/emif_defs.h |9 +
include/configs/davinci_dm355evm.h |1 +
include/configs/davinci_dm355leopard.h |1 +
include/configs/davinci_dm365evm.h |1 +
include/configs/davinci_dm6467evm.h |1 +
include/configs/davinci_dvevm.h |1 +
include/configs/davinci_schmoogie.h |1 +
include/configs/davinci_sffsdr.h |1 +
include/configs/davinci_sonata.h |1 +
10 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index eabaf3e..1900a1a 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -82,12 +82,13 @@ static void nand_davinci_hwcontrol(struct mtd_info *mtd,
int cmd, unsigned int c
static void nand_davinci_enable_hwecc(struct mtd_info *mtd, int mode)
{
- int dummy;
+ u_int32_t val;
- dummy = emif_regs->NANDF1ECC;
+ val = readl(&emif_regs->NANDF1ECC);
- /* FIXME: only chipselect 0 is supported for now */
- emif_regs->NANDFCR |= 1 << 8;
+ val = readl(&emif_regs->NANDFCR);
+ val |= DAVINCI_NANDFCR_1BIT_ECC_START(CONFIG_SYS_NAND_CS);
+ writel(val, &emif_regs->NANDFCR);
}
static u_int32_t nand_davinci_readecc(struct mtd_info *mtd, u_int32_t region)
@@ -214,8 +215,11 @@ static void nand_davinci_4bit_enable_hwecc(struct mtd_info
*mtd, int mode)
* Start a new ECC calculation for reading or writing 512 bytes
* of data.
*/
- val = (emif_regs->NANDFCR & ~(3 << 4)) | (1 << 12);
- emif_regs->NANDFCR = val;
+ val = readl(&emif_regs->NANDFCR);
+ val &= ~DAVINCI_NANDFCR_4BIT_ECC_SEL_MASK;
+ val |= DAVINCI_NANDFCR_4BIT_ECC_SEL(CONFIG_SYS_NAND_CS);
+ val |= DAVINCI_NANDFCR_4BIT_ECC_START;
+ writel(val, &emif_regs->NANDFCR);
break;
case NAND_ECC_READSYN:
val = emif_regs->NAND4BITECC1;
diff --git a/include/asm-arm/arch-davinci/emif_defs.h
b/include/asm-arm/arch-davinci/emif_defs.h
index c91e30c..5a36ece 100644
--- a/include/asm-arm/arch-davinci/emif_defs.h
+++ b/include/asm-arm/arch-davinci/emif_defs.h
@@ -68,4 +68,13 @@ typedef struct {
} emif_registers;
typedef emif_registers *emifregs;
+
+#define DAVINCI_NANDFCR_4BIT_ECC_SEL_MASK (3 << 4)
+#define DAVINCI_NANDFCR_4BIT_ECC_SEL(n)((n-2) << 4)
+
+#define DAVINCI_NANDFCR_1BIT_ECC_START(n) (1 << (8 + (n-2)))
+
+#define DAVINCI_NANDFCR_4BIT_ECC_START (1 << 12)
+#define DAVINCI_NANDFCR_4BIT_CALC_START(1 << 13)
+
#endif
diff --git a/include/configs/davinci_dm355evm.h
b/include/configs/davinci_dm355evm.h
index ea40df0..07914a3 100644
--- a/include/configs/davinci_dm355evm.h
+++ b/include/configs/davinci_dm355evm.h
@@ -66,6 +66,7 @@
/* NAND: socketed, two chipselects, normally 2 GBytes */
#define CONFIG_NAND_DAVINCI
+#define CONFIG_SYS_NAND_CS 2
#define CONFIG_SYS_NAND_USE_FLASH_BBT
#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
#define CONFIG_SYS_NAND_PAGE_2K
diff --git a/include/configs/davinci_dm355leopard.h
b/include/configs/davinci_dm355leopard.h
index 5db720e..54b153d 100644
--- a/include/configs/davinci_dm355leopard.h
+++ b/include/configs/davinci_dm355leopard.h
@@ -65,6 +65,7 @@
/* NAND */
#define CONFIG_NAND_DAVINCI
+#define CONFIG_SYS_NAND_CS 2
#define CONFIG_SYS_NAND_USE_FLASH_BBT
#define CONFIG_SYS_NAND_HW_ECC
diff --git a/include/configs/davinci_dm365evm.h
b/include/configs/davinci_dm365evm.h
index 53a105b..5a510e6 100644
--- a/include/configs/davinci_dm365evm.h
+++ b/include/configs/davinci_dm365evm.h
@@ -74,6 +74,7 @@
/* NAND: socketed, two chipselects, normally 2 GBytes */
#define CONFIG_NAND_DAVINCI
+#define CONFIG_SYS_NAND_CS 2
#define CONFIG_SYS_NAND_USE_FLASH_BBT
#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
#define CONFIG_SYS_NAND_PAGE_2K
diff --git a/include/configs/davinci_dm6467evm.h
b/include/configs/davinci_dm6467evm.h
index 6617941..dce0411 100644
--- a/include/configs/davinci_dm6467evm.h
+++ b/include/configs/davinci_dm6467evm.h
@@ -75,6 +75,7 @@
#define CONFIG_SYS_NO_FLASH
#ifdef CONFIG_SYS_USE_NAND
#define
Re: [U-Boot] [PATCH] TI: DaVinci: Updating EMAC driver for DM365 and DM646x
Hi Nick,
> -Original Message-
> From: Nick Thompson [mailto:nick.thomp...@gefanuc.com]
> Sent: Monday, November 16, 2009 11:47 AM
> To: Paulraj, Sandeep
> Cc: u-boot@lists.denx.de; biggerbadder...@gmail.com
> Subject: Re: [U-Boot] [PATCH] TI: DaVinci: Updating EMAC driver for DM365
> and DM646x
>
> Hi Sandeep,
>
> On 13/11/09 20:42, s-paul...@ti.com wrote:
> > From: Sandeep Paulraj
> >
> > The EMAC IP on DM365 and DM646x is slightly different from
> > that on DM644x. This patch updates the DaVinci EMAC driver
> > so that EMAC becomes operational on DM365 in U-Boot.
> > A flag 'CONFIG_DAVINCI_EMAC_VERSION2' is used in the driver.
> > This flag will need to be defined in the DM365 config file.
> >
> > Signed-off-by: Sandeep Paulraj
> > ---
> > The same modifications work on DM646x in a slightly older version
> > of U-Boot. So when enabled this should work on the DM6467 EVM as well.
> > This has at this point of time not been tested on the DM6467 in the
> latest
> > version of U-Boot.
> > drivers/net/davinci_emac.c | 79
> ++-
> > 1 files changed, 77 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> > index fa8cee4..1df98e9 100644
> > --- a/drivers/net/davinci_emac.c
> > +++ b/drivers/net/davinci_emac.c
> > @@ -107,6 +107,33 @@ static void davinci_eth_mdio_enable(void)
> > while (adap_mdio->CONTROL & MDIO_CONTROL_IDLE) {;}
> > }
> >
> > +/* Read a PHY register via MDIO inteface */
> > +static int mdio_read(int phy_addr, int reg_num)
> > +{
> > + adap_mdio->USERACCESS0 = MDIO_USERACCESS0_GO |
> > + MDIO_USERACCESS0_WRITE_READ |
> > + ((reg_num & 0x1F) << 21) |
> > + ((phy_addr & 0x1F) << 16);
> > +
> > + /* Wait for command to complete */
> > + while (adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO);
> > +
> > + return adap_mdio->USERACCESS0 & 0x;
> > +}
> > +
> > +/* Write to a PHY register via MDIO inteface */
> > +void mdio_write(int phy_addr, int reg_num, unsigned int data)
> > +{
> > + /* Wait for User access register to be ready */
> > + while (adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO);
> > +
> > + adap_mdio->USERACCESS0 = MDIO_USERACCESS0_GO |
> > + MDIO_USERACCESS0_WRITE_WRITE |
> > + ((reg_num & 0x1F) << 21) |
> > + ((phy_addr & 0x1F) << 16) |
> > + (data & 0x);
> > +}
> > +
> > /*
> > * Tries to find an active connected PHY. Returns 1 if address if
> found.
> > * If no active PHY (or more than one PHY) found returns 0.
> > @@ -248,6 +275,31 @@ static int davinci_mii_phy_write(char *devname,
> unsigned char addr, unsigned cha
> >
> > #endif
> >
> > +static void emac_gigabit_enable(void)
> > +{
> > + int temp;
> > +
> > + temp = mdio_read(EMAC_MDIO_PHY_NUM, 0);
> > +
> > + if (temp & (1 << 6)) {
> > + /*
> > +* Check if link detected is giga-bit
> > +* If Gigabit mode detected, enable gigbit in MAC and PHY
> > +*/
> > + adap_emac->MACCONTROL |= EMAC_MACCONTROL_GIGFORCE |
> > + EMAC_MACCONTROL_GIGABIT_ENABLE;
> > +
> > + /*
> > +* The SYS_CLK which feeds the SOC for giga-bit operation
> > +* does not seem to be enabled after reset as expected.
> > +* Force enabling SYS_CLK by writing to the PHY
> > +*/
> > + temp = mdio_read(EMAC_MDIO_PHY_NUM, 22);
> > + temp |= (1 << 4);
> > + mdio_write(EMAC_MDIO_PHY_NUM, 22, temp);
> > + }
> > +}
> > +
>
> Do all DaVinci boards have gigabit?
No they do not
> Unsurprisingly, I'm coming from the
> point
> of view that DA830 at least doesn't have this. I wonder if it going to be
> safe
> to modify these bits across the DaVinci range?
This function will be called by only those that have this feature.
This function will be called by only DM365 and DM6467.
>
> >
> > /* Eth device open */
> > static int davinci_eth_open(struct eth_device *dev, bd_t *bis)
> > @@ -261,10 +313,15 @@ static int davinci_eth_open(struct eth_device
> *dev, bd_t *bis)
> > /* Reset EMAC module and disable interrupts in wrapper */
> > adap_emac->SOFTRESET = 1;
> > while (adap_emac->SOFTRESET != 0) {;}
> > +#if defined(CONFIG_DAVINCI_EMAC_VERSION2)
> > + adap_ewrap->SOFTRST = 1;
> > + while (adap_ewrap->SOFTRST != 0);
> > +#else
> > adap_ewrap->EWCTL = 0;
> > for (cnt = 0; cnt < 5; cnt++) {
> > clkdiv = adap_ewrap->EWCTL;
> > }
> > +#endif
> >
> > rx_desc = emac_rx_desc;
> >
> > @@ -282,6 +339,10 @@ static int davinci_eth_open(struct eth_device *dev,
> bd_t *bis)
> > adap_emac->MACADDRLO =
> > (davinci_eth_mac_addr[5] << 8) |
> > (davinci_eth_mac_addr[4])
Re: [U-Boot] [PATCH] TI: DaVinci: Updating EMAC driver for DM365 and DM646x
Hi Sandeep,
On 13/11/09 20:42, s-paul...@ti.com wrote:
> From: Sandeep Paulraj
>
> The EMAC IP on DM365 and DM646x is slightly different from
> that on DM644x. This patch updates the DaVinci EMAC driver
> so that EMAC becomes operational on DM365 in U-Boot.
> A flag 'CONFIG_DAVINCI_EMAC_VERSION2' is used in the driver.
> This flag will need to be defined in the DM365 config file.
>
> Signed-off-by: Sandeep Paulraj
> ---
> The same modifications work on DM646x in a slightly older version
> of U-Boot. So when enabled this should work on the DM6467 EVM as well.
> This has at this point of time not been tested on the DM6467 in the latest
> version of U-Boot.
> drivers/net/davinci_emac.c | 79 ++-
> 1 files changed, 77 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index fa8cee4..1df98e9 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -107,6 +107,33 @@ static void davinci_eth_mdio_enable(void)
> while (adap_mdio->CONTROL & MDIO_CONTROL_IDLE) {;}
> }
>
> +/* Read a PHY register via MDIO inteface */
> +static int mdio_read(int phy_addr, int reg_num)
> +{
> + adap_mdio->USERACCESS0 = MDIO_USERACCESS0_GO |
> + MDIO_USERACCESS0_WRITE_READ |
> + ((reg_num & 0x1F) << 21) |
> + ((phy_addr & 0x1F) << 16);
> +
> + /* Wait for command to complete */
> + while (adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO);
> +
> + return adap_mdio->USERACCESS0 & 0x;
> +}
> +
> +/* Write to a PHY register via MDIO inteface */
> +void mdio_write(int phy_addr, int reg_num, unsigned int data)
> +{
> + /* Wait for User access register to be ready */
> + while (adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO);
> +
> + adap_mdio->USERACCESS0 = MDIO_USERACCESS0_GO |
> + MDIO_USERACCESS0_WRITE_WRITE |
> + ((reg_num & 0x1F) << 21) |
> + ((phy_addr & 0x1F) << 16) |
> + (data & 0x);
> +}
> +
> /*
> * Tries to find an active connected PHY. Returns 1 if address if found.
> * If no active PHY (or more than one PHY) found returns 0.
> @@ -248,6 +275,31 @@ static int davinci_mii_phy_write(char *devname, unsigned
> char addr, unsigned cha
>
> #endif
>
> +static void emac_gigabit_enable(void)
> +{
> + int temp;
> +
> + temp = mdio_read(EMAC_MDIO_PHY_NUM, 0);
> +
> + if (temp & (1 << 6)) {
> + /*
> + * Check if link detected is giga-bit
> + * If Gigabit mode detected, enable gigbit in MAC and PHY
> + */
> + adap_emac->MACCONTROL |= EMAC_MACCONTROL_GIGFORCE |
> + EMAC_MACCONTROL_GIGABIT_ENABLE;
> +
> + /*
> + * The SYS_CLK which feeds the SOC for giga-bit operation
> + * does not seem to be enabled after reset as expected.
> + * Force enabling SYS_CLK by writing to the PHY
> + */
> + temp = mdio_read(EMAC_MDIO_PHY_NUM, 22);
> + temp |= (1 << 4);
> + mdio_write(EMAC_MDIO_PHY_NUM, 22, temp);
> + }
> +}
> +
Do all DaVinci boards have gigabit? Unsurprisingly, I'm coming from the point
of view that DA830 at least doesn't have this. I wonder if it going to be safe
to modify these bits across the DaVinci range?
>
> /* Eth device open */
> static int davinci_eth_open(struct eth_device *dev, bd_t *bis)
> @@ -261,10 +313,15 @@ static int davinci_eth_open(struct eth_device *dev,
> bd_t *bis)
> /* Reset EMAC module and disable interrupts in wrapper */
> adap_emac->SOFTRESET = 1;
> while (adap_emac->SOFTRESET != 0) {;}
> +#if defined(CONFIG_DAVINCI_EMAC_VERSION2)
> + adap_ewrap->SOFTRST = 1;
> + while (adap_ewrap->SOFTRST != 0);
> +#else
> adap_ewrap->EWCTL = 0;
> for (cnt = 0; cnt < 5; cnt++) {
> clkdiv = adap_ewrap->EWCTL;
> }
> +#endif
>
> rx_desc = emac_rx_desc;
>
> @@ -282,6 +339,10 @@ static int davinci_eth_open(struct eth_device *dev, bd_t
> *bis)
> adap_emac->MACADDRLO =
> (davinci_eth_mac_addr[5] << 8) |
> (davinci_eth_mac_addr[4]);
> +#if defined(CONFIG_DAVINCI_EMAC_VERSION2)
> + /* Set the Match and Valid Bits */
> + adap_emac->MACADDRLO |= (1 << 19) | (1 << 20);
> +#endif
>
> adap_emac->MACHASH1 = 0;
> adap_emac->MACHASH2 = 0;
> @@ -347,8 +408,15 @@ static int davinci_eth_open(struct eth_device *dev, bd_t
> *bis)
> clkdiv = (EMAC_MDIO_BUS_FREQ / EMAC_MDIO_CLOCK_FREQ) - 1;
> adap_mdio->CONTROL = ((clkdiv & 0xff) | MDIO_CONTROL_ENABLE |
> MDIO_CONTROL_FAULT);
>
> +#if defined(CONFIG_DAVINCI_EMAC_VERSION2)
> + /* We need to wait for MDIO to start */
> +
Re: [U-Boot] [PATCH v2] Fix build failure in examples/standalone
> -Original Message- > From: Premi, Sanjeev > Sent: Monday, November 09, 2009 10:43 PM > To: u-boot@lists.denx.de > Cc: Premi, Sanjeev > Subject: [PATCH v2] Fix build failure in examples/standalone > > Some versions of 'make' do not handle trailing white-spaces > properly. Trailing spaces in ELF causes a 'fake' source to > be added to the variable COBJS; leading to build failure > (listed below). The problem was found with GNU Make 3.80. > > Using text-function 'strip' as a workaround for the problem. > > make[1]: Entering directory `/home/sanjeev/u-boot/examples/standalone' > arm-none-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 > -msoft-float > -D__KERNEL__ -DTEXT_BASE=0x80e8 -I/home/sanjeev/u-boot/include > -fno-builtin -ffreestanding -nostdinc -isystem > /opt/codesourcery/2009q1- > 203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/include -pipe > -DCONFIG_ > ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork > -march=armv5 > -Wall -Wstrict-prototypes -fno-stack-protector -g -Os > -fno-common -ff > ixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e8 > -I/home/sanje > ev/u-boot/include -fno-builtin -ffreestanding -nostdinc > -isystem /opt/co > desourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4. > 3.3/includ > e -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux > -mno-thumb-inte > rwork -march=armv5 -I.. -Bstatic -T u-boot.lds -Ttext > 0x80e8 -o .c > arm-none-linux-gnueabi-gcc: no input files > make[1]: *** [.c] Error 1 > make[1]: Leaving directory `/home/sanjeev/u-boot/examples/standalone' > make: *** [examples/standalone] Error 2 > premi # > > Signed-off-by: Sanjeev Premi > --- > examples/standalone/Makefile |8 +++- > 1 files changed, 7 insertions(+), 1 deletions(-) > > diff --git a/examples/standalone/Makefile > b/examples/standalone/Makefile > index 5e2f2bc..c02ce43 100644 > --- a/examples/standalone/Makefile > +++ b/examples/standalone/Makefile > @@ -38,7 +38,13 @@ ELF-mpc8260 += > mem_to_mem_idma2intr > ELF-ppc += sched > ELF-oxc += eepro100_eeprom > > -ELF := $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU)) > +# > +# Some versions of make do not handle trailing white spaces properly; > +# leading to build failures. The problem was found with GNU > Make 3.80. > +# Using 'strip' as a workaround for the problem. > +# > +ElF := $(strip $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU))) > + > SREC = $(addsuffix .srec,$(ELF)) > BIN = $(addsuffix .bin,$(ELF)) > > -- > 1.6.2.2 > > Hi, Just wanted to check if this update is okay? Best regards, Sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] OMAP3: add CM-T35 board
Tom wrote: > Mike Rapoport wrote: >> Tom, >> >> Tom wrote: >>> Paulraj, Sandeep wrote: > Add CM-T35 board support > >>> Please add more description of the board. >>> > Signed-off-by: Mike Rapoport > > -- > v2 changes: > - rename board config file from omap3_cm-t35.h to cm-t35.h > - remove SZ_xx references > - add MAKEALL/MAINTEINERS entries >>> >>> Wolfgang had made this comment on V2 that has not been addressed. >>> > diff --git a/include/configs/cm-t35.h b/include/configs/cm-t35.h > new file mode 100755 >> index 000..b881112 >> --- /dev/null >> +++ b/include/configs/cm-t35.h ... >> +#ifndef __ASSEMBLY__ >> +extern struct gpmc *gpmc_cfg; >> +extern unsigned int boot_flash_base; >> +extern volatile unsigned int boot_flash_env_addr; >> +extern unsigned int boot_flash_off; >> +extern unsigned int boot_flash_sec; >> +extern unsigned int boot_flash_type; >> +#endif These should not be needed in your board config file. Please move to a more appropriate header. >> >> As I've already answered Wolfgang ([1]), this is what _all_ other >> omap3 board >> do... Moving these requires rework of common omap3 code and updates to >> all omap3 >> boards. >> >> > > Yes this change would apply to all the omap3 boards. > But it looks like they are are all the same change. > > The change per board, would be to delete these externs once the > first code change is made. > > Since this is a code movement change, it can be verified by running > MAKEALL arm before and after the change. The problem here, that just moving these externs to e.g. include/arm-arm/arch-omap3/mem.h is not enough. All omap3 boards set environment related defines to these externs, and therefore without them common/env_nand does not build. It seems that all the board_flash_* variables can be completely removed completely, but I really don't know what was the original author intention about those variables. > Tom > > -- Sincerely yours, Mike. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3 CORRECTED] Initial support for Marvell Orion5x SoC
> -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Monday, November 16, 2009 2:52 PM > To: Prafulla Wadaskar > Cc: U-Boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH V2 1/3 CORRECTED] Initial > support for Marvell Orion5x SoC > > Hi Rafulla, > > Prafulla Wadaskar a écrit : > > > > Please post this patch as v3 with above description as > change log for v3 > > > > Regards.. > > Prafulla . . . > > Seeing as I have also some fixes to do on patch V2 3/3, I'll > report a > whole V3 patch set with the description in the cover letter. > Is that fine? Change log is important to understand reviewers and other community friends to understand the history of the patch. In each patch you should maintain change log after line containing "---" when patch will be applied, only commit log will be considered. So please segregate your information carefully. Cover letter is optional, you better put enough information in the commit log relevant to patch Regards.. Prafulla . . > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] OMAP3: add CM-T35 board
Mike Rapoport wrote: > Tom, > > Tom wrote: >> Paulraj, Sandeep wrote: Add CM-T35 board support >> Please add more description of the board. >> Signed-off-by: Mike Rapoport -- v2 changes: - rename board config file from omap3_cm-t35.h to cm-t35.h - remove SZ_xx references - add MAKEALL/MAINTEINERS entries >> >> Wolfgang had made this comment on V2 that has not been addressed. >> >>> > diff --git a/include/configs/cm-t35.h b/include/configs/cm-t35.h new file mode 100755 > index 000..b881112 > --- /dev/null > +++ b/include/configs/cm-t35.h >>> ... > +#ifndef __ASSEMBLY__ > +extern struct gpmc *gpmc_cfg; > +extern unsigned int boot_flash_base; > +extern volatile unsigned int boot_flash_env_addr; > +extern unsigned int boot_flash_off; > +extern unsigned int boot_flash_sec; > +extern unsigned int boot_flash_type; > +#endif >>> These should not be needed in your board config file. Please move to a >>> more appropriate header. > > As I've already answered Wolfgang ([1]), this is what _all_ other omap3 board > do... Moving these requires rework of common omap3 code and updates to all > omap3 > boards. > > Yes this change would apply to all the omap3 boards. But it looks like they are are all the same change. The change per board, would be to delete these externs once the first code change is made. Since this is a code movement change, it can be verified by running MAKEALL arm before and after the change. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EHCI hub not powering on port
Hi, On Friday 13 November 2009 17:02:26 Florian Fainelli wrote: > Hi all, > > I am trying to make u-boot work with my EHCI controler and everything goes > well up to when it comes to powering on the port: Forgot to mention that the hardware works fine with Linux and does not require any specific quirk. > > Register 10011 NbrPorts 1 > USB EHCI 1.00 > scanning bus for devices... New Device 0 > usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 > length 0x40 set address 1 > usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length > 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index > 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value > 0x200 index 0x0 length 0x9 usb_control_msg: request: 0x6, requesttype: > 0x80, value 0x200 index 0x0 length 0x19 get_conf_no 0 Result 25, wLength > 25 > if 0, ep 0 > ##EP epmaxpacketin[1] = 8 > set configuration 1 > usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length > 0x0 new device strings: Mfr=1, Product=2, SerialNumber=0 > usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 > length 0xFF USB device number 1 default language ID 0x1 > usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 > length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 > index 0x1 length 0xFF Manufacturer u-boot > Product EHCI Host Controller > SerialNumber > USB hub found > usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 > length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 > index 0x0 length 0x8 1 ports detected > individual port power switching > standalone hub > individual port over-current protection > power on to power good time: 20ms > hub controller current requirement: 0mA > port 1 is removable > usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 > length 0x4 get_hub_status returned status 0001, change 0901 > local power source is lost (inactive) > no over-current condition exists > enabling power on all ports > usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 > length 0x0 port 1 returns 0 > usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 > length 0x4 Port 1 Status 0502 Change > 1 USB Device(s) found >scanning bus for storage devices... 0 Storage Device(s) found > > > According to the USB 2.0 specification paragraph 11.11, this is the correct > behavior since both HUB_STATUS_LOCAL_POWER in wHubStatus and > HUB_CHANGE_LOCAL_POWER in wHubChange are set. Issuing a port power feature > to the port would have no effect. > > Has anyone already met similar problems with EHCI hubs integrated to EHCI > controllers ? > > Thank you very much in advance. > -- Florian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot: How to read file from FAT filesystem on NorFlash MTD partition
Dear Wolfgang Denk, Sorry for the simple question, but I can't find the document to guide me to read file from FAT file system in NOR FLASH. On Mon, Nov 16, 2009 at 3:40 PM, Wolfgang Denk wrote: > Dear Xianwei Zeng, > > In message <52c6d4120911151729s61a250e0j1b0ec02b43191...@mail.gmail.com> > you wrote: > > > > Yes. I didn't enable the mtdparts support. I will try it. > > > > Do I need to write extra driver, for example something I was doing, > > writing FAT + MTD support? > > No, you don't need any special drivers. > > After I enbale CONFIG_CMD_MTDPARTS, I can get MTD partition information. For example, I set env to: mtdids=nor0=smt300-nor mtdparts=mtdparts=smt300-nor:46...@0x0008(sys)ro And then I can use mtdparts command to list the partition info: device nor0 , # parts = 1 #: namesizeoffset mask_flags 0: sys 0x0048 0x0008 1 But I still don't know the way how to read file inside this FAT filesystem. * Which command can do this? (fatload seems can not because the interface is not known) * From which verion u-boot supports this feature? Our u-boot is based v2009.08. Do we need to update to latest one? (v2009.11-rc1) Any document you suggest me to read? u-boot/README is not enough. Thank you very much. -- Best Regards Xianwei ZENG Linux Fans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Davinci: Table driven pinmux configuration
Davinci: Table driven pinmux configuration
Add code to allow pinmux_config tables to be grouped and configured
as a single resource. This removes multiple calls to the pinmux
configuration code from board_init and allows pinmuxes to be
individually configured and added by data manipulation only.
All related #ifdefs can the be removed from board_init code and
since the compiler optimises away statics, #ifdefs can be reduced in
the data definitions as well.
Signed-off-by: Nick Thompson
---
Applies to u-boot-ti:
board/davinci/common/misc.c | 31 +++
board/davinci/common/misc.h | 13 +
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c
index 9fab76f..25ca326 100644
--- a/board/davinci/common/misc.c
+++ b/board/davinci/common/misc.c
@@ -155,3 +155,34 @@ int davinci_configure_pin_mux(const struct pinmux_config
*pins,
return 0;
}
+
+/*
+ * Configure multiple pinmux resources.
+ *
+ * Takes an pinmux_resource array of pinmux_config and pin counts:
+ *
+ * const struct pinmux_resource pinmuxes[] = {
+ * PINMUX_ITEM(uart_pins),
+ * PINMUX_ITEM(i2c_pins),
+ * };
+ *
+ * The number of items in the array must be passed (ARRAY_SIZE can provide
+ * this value conveniently).
+ *
+ * Each item entry is configured in the defined order. If configuration
+ * of any item fails, -1 is returned and none of the following items are
+ * configured. On success, 0 is returned.
+ */
+int davinci_configure_pin_mux_items(const struct pinmux_resource *item,
+ const int n_items)
+{
+ int i;
+
+ for (i = 0; i < n_items; i++) {
+ if (davinci_configure_pin_mux(item[i].pins,
+ item[i].n_pins) != 0)
+ return -1;
+ }
+
+ return 0;
+}
diff --git a/board/davinci/common/misc.h b/board/davinci/common/misc.h
index f6d8b1b..329c369 100644
--- a/board/davinci/common/misc.h
+++ b/board/davinci/common/misc.h
@@ -34,8 +34,21 @@ struct pinmux_config {
unsigned char field; /* field number */
};
+/* pin table definition */
+struct pinmux_resource {
+ const struct pinmux_config *pins;
+ const int n_pins;
+};
+
+#define PINMUX_ITEM(item) { \
+ .pins = item, \
+ .n_pins = ARRAY_SIZE(item) \
+ }
+
int dvevm_read_mac_address(uint8_t *buf);
void dv_configure_mac_address(uint8_t *rom_enetaddr);
int davinci_configure_pin_mux(const struct pinmux_config *pins, int n_pins);
+int davinci_configure_pin_mux_items(const struct pinmux_resource *item,
+ int n_items);
#endif /* __MISC_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3 CORRECTED] Initial support for Marvell Orion5x SoC
Hi Rafulla, Prafulla Wadaskar a écrit : > > Please post this patch as v3 with above description as change log for v3 > > Regards.. > Prafulla . . . Seeing as I have also some fixes to do on patch V2 3/3, I'll report a whole V3 patchset with the description in the cover letter. Is that fine? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] DA8xx: Add MUSB host support
On 13/11/09 16:47, Gupta, Ajay Kumar wrote:
> Hi,
>> Tested USB host functionality on DA830 EVM.
>>
>> Signed-off-by: Ajay Kumar Gupta
>> Signed-off-by: Swaminathan S
>> ---
>
>
>
>> --- a/include/usb.h
>> +++ b/include/usb.h
>> @@ -183,7 +183,8 @@ struct usb_device {
>> #if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \
>> defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \
>> defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) || \
>> - defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI)
>> + defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI) || \
>> + defined(CONFIG_USB_DA8XX)
>
>> These are aligned incorrectly (should be 4 spaces rather than a tab)
> It was originally with tabs only. Are you suggesting to change all 5 lines to
> match the alignment ?
I originally thought this was a da8xx specific file. It is not, so no, I
don't expect you the change the indentation - what you have looks fine.
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] OMAP3: add CM-T35 board
Tom, Tom wrote: > Paulraj, Sandeep wrote: >>> Add CM-T35 board support >>> > > Please add more description of the board. > >>> Signed-off-by: Mike Rapoport >>> >>> -- >>> v2 changes: >>> - rename board config file from omap3_cm-t35.h to cm-t35.h >>> - remove SZ_xx references >>> - add MAKEALL/MAINTEINERS entries > > > Wolfgang had made this comment on V2 that has not been addressed. > >> > diff --git a/include/configs/cm-t35.h b/include/configs/cm-t35.h >> > new file mode 100755 >> > > index 000..b881112 >> > > --- /dev/null >> > > +++ b/include/configs/cm-t35.h >> ... >> > > +#ifndef __ASSEMBLY__ >> > > +extern struct gpmc *gpmc_cfg; >> > > +extern unsigned int boot_flash_base; >> > > +extern volatile unsigned int boot_flash_env_addr; >> > > +extern unsigned int boot_flash_off; >> > > +extern unsigned int boot_flash_sec; >> > > +extern unsigned int boot_flash_type; >> > > +#endif >> >> These should not be needed in your board config file. Please move to a >> more appropriate header. As I've already answered Wolfgang ([1]), this is what _all_ other omap3 board do... Moving these requires rework of common omap3 code and updates to all omap3 boards. [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/71466 >> Best regards, >> >> Wolfgang Denk > > Please do not push this change. > > Tom > > -- Sincerely yours, Mike. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] Add support for the LaCie ED Mini V2 board
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud > Sent: Sunday, November 15, 2009 4:33 AM > To: U-Boot@lists.denx.de > Subject: [U-Boot] [PATCH V2 3/3] Add support for the LaCie ED > Mini V2 board > > This board is based on the Marvell Orion5x SoC. > Current support is limited to console and Flash. > Flash support uses LEGACY as the Macronix 29LV400 > used on ED Mini V2 is not 100% CFI compliant. > > Signed-off-by: Albert Aribaud > --- > MAINTAINERS |4 + > MAKEALL |1 + > Makefile|3 + > board/LaCie/edminiv2/Makefile | 54 +++ > board/LaCie/edminiv2/config.mk | 27 +++ > board/LaCie/edminiv2/edminiv2.c | 134 > > board/LaCie/edminiv2/edminiv2.h | 43 > include/configs/edminiv2.h | 143 > +++ > 8 files changed, 409 insertions(+), 0 deletions(-) > create mode 100644 board/LaCie/edminiv2/Makefile > create mode 100644 board/LaCie/edminiv2/config.mk > create mode 100644 board/LaCie/edminiv2/edminiv2.c > create mode 100644 board/LaCie/edminiv2/edminiv2.h > create mode 100644 include/configs/edminiv2.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index d70a9d2..93e57f5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -512,6 +512,10 @@ Unknown / orphaned boards: > #Board CPU > # > > ## > ### > > +Albert ARIBAUD > + > + edminiv2ARM926EJS (Orion5x SoC) > + That's good if you can move this entry above Albin Tonnerre's entry ...snip... > + MPP17_GPIO, > + MPP18_GPIO, > + MPP19_GPIO, Why not configured rest 6 gpios ? ...snip... > + > +/* > + * GPIOs for LaCie ED Mini: > + * GPIO3 is input (RTC interrupt) > + * GPIO16 is Power LED control (0 = on, 1 = off) > + * GPIO17 is Power LED source select (0 = CPLD, 1 = GPIO16) > + * GPIO18 is Power Button status (0 = Released, 1 = Pressed) > + * > + * Default is LED ON > + */ > + > +#define EDMINIV2_OE 0xfffc > +#define EDMINIV2_OE_VAL 0x0002 How about adding GPIO_OE? This settings are referred to GPIOs register ...snip... > +#define CONFIG_IDENT_STRING " EDMiniV2" > + > +/* > + * High Level Configuration Options (easy to change) > + */ > +#define CONFIG_MARVELL 1 > +#define CONFIG_ARM926EJS 1 /* Basic Architecture */ > +#define CONFIG_FEROCEON 1 /* CPU Core > subversion */ > +#define CONFIG_ORION5X 1 /* SOC Family Name */ > +#define CONFIG_88F5182 1 /* SOC Name */ > +#define CONFIG_MACH_EDMINIV2 1 /* Machine type */ > + > +#define CONFIG_SKIP_LOWLEVEL_INIT/* disable board > lowlevel_init */ How you are addressing DRAM configuration? I think you need lowlevel_init. ...snip... > +/* > + * Environment variables configurations > + */ > +#define CONFIG_ENV_IS_IN_FLASH 1 > +#define CONFIG_ENV_SECT_SIZE 0x2000 /* 16K */ > +#define CONFIG_ENV_SIZE 0x2000 > +#define CONFIG_ENV_OFFSET0x4000 /* env starts here */ I don't know how this is going to work, how much flash do you have? I hope it is mapped in the end since your reset address is 0x. Where is the code to fetch flashed image from flash to DRAM at TEXT_BASE? I suggest you provide some more details about your board in the commit log > + > +/* > + * Size of malloc() pool > + */ > +#define CONFIG_SYS_MALLOC_LEN(1024 * 128) /* 128kB > for malloc() */ > +/* size in bytes reserved for initial data */ > +#define CONFIG_SYS_GBL_DATA_SIZE 128 > + > +/* > + * Other required minimal configurations > + */ > +#define CONFIG_CONSOLE_INFO_QUIET/* some code reduction */ > +#define CONFIG_ARCH_CPU_INIT /* call arch_cpu_init() */ > +#define CONFIG_ARCH_MISC_INIT/* call arch_misc_init() */ > +#define CONFIG_DISPLAY_CPUINFO /* Display cpu info */ > +#define CONFIG_NR_DRAM_BANKS 4 > +#define CONFIG_STACKSIZE 0x0010 /* regular stack- 1M */ > +#define CONFIG_SYS_LOAD_ADDR 0x0080 /* default load > adr- 8M */ > +#define CONFIG_SYS_MEMTEST_START 0x0040 /* 4M */ > +#define CONFIG_SYS_MEMTEST_END 0x007f /*(_8M -1) */ > +#define CONFIG_SYS_RESET_ADDRESS 0x /* Rst Vector Adr */ Same comment applies here Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHi v5] OMAP3: add CM-T35 board
CM-T35 is a system-on-module board from CompuLab, Ltd. The CM-T35 datasheet can be found at http://www.compulab.co.il/t35/html/t35-cm-datasheet.htm Signed-off-by: Mike Rapoport -- v2 changes: - rename board config file from omap3_cm-t35.h to cm-t35.h - remove SZ_xx references - add MAKEALL/MAINTEINERS entries v3 changes: - fix whitespace and indentation - remove eth_init from board_eth_init - add CM-T35 entry to doc/README.omap3 - fixed board name in MAINTAINERS v4 changes: - rebased agains u-boot-ti/next branch v5 changes: - rename board files to cm_t35 - add explicit setup of GPMC with SMNAND configuration - reorginize Ethernet initialization so that I2C related code will depend on I2C initialization --- MAINTAINERS |4 + MAKEALL |1 + Makefile |2 + board/cm_t35/Makefile| 47 +++ board/cm_t35/cm_t35.c| 216 + board/cm_t35/cm_t35.h| 173 ++ board/cm_t35/config.mk | 30 + doc/README.omap3 | 16 ++- include/configs/cm_t35.h | 299 ++ 9 files changed, 786 insertions(+), 2 deletions(-) create mode 100644 board/cm_t35/Makefile create mode 100644 board/cm_t35/cm_t35.c create mode 100644 board/cm_t35/cm_t35.h create mode 100644 board/cm_t35/config.mk create mode 100644 include/configs/cm_t35.h diff --git a/MAINTAINERS b/MAINTAINERS index d70a9d2..94e45f4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -677,6 +677,10 @@ Stelian Pop at91sam9263ek ARM926EJS (AT91SAM9263 SoC) at91sam9rlekARM926EJS (AT91SAM9RL SoC) +Mike Rapoport + + cm_t35 ARM CORTEX-A8 (OMAP3xx SoC) + Tom Rix omap3_zoom2 ARM CORTEX-A8 (OMAP3xx SoC) diff --git a/MAKEALL b/MAKEALL index d63c5c2..e131c62 100755 --- a/MAKEALL +++ b/MAKEALL @@ -612,6 +612,7 @@ LIST_ARM11="\ ## ARM Cortex-A8 Systems # LIST_ARM_CORTEX_A8=" \ + cm_t35 \ devkit8000 \ omap3_beagle\ omap3_overo \ diff --git a/Makefile b/Makefile index bcb3fe9..9d6150a 100644 --- a/Makefile +++ b/Makefile @@ -3143,6 +3143,8 @@ SMN42_config : unconfig # ## ARM CORTEX Systems # +cm_t35_config :unconfig + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 cm_t35 NULL omap3 devkit8000_config :unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 devkit8000 timll omap3 diff --git a/board/cm_t35/Makefile b/board/cm_t35/Makefile new file mode 100644 index 000..320a817 --- /dev/null +++ b/board/cm_t35/Makefile @@ -0,0 +1,47 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# 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 $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := cm_t35.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend diff --git a/board/cm_t35/cm_t35.c b/board/cm_t35/cm_t35.c new file mode 100644 index 000..0ba23cc --- /dev/null +++ b/board/cm_t35/cm_t35.c @@ -0,0 +1,216 @@ +/* + * (C) Copyright 2009 + * CompuLab, Ltd. + * + * Authors : + * Igor Vaisbein + * Mike Rapoport + * + * Derived from omap3evm and Beagle Board by + * Manikandan Pillai + * Richard Woodruff + * Syed Mohammed Khasim + * + * 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 +
Re: [U-Boot] [PATCH V2 1/3 CORRECTED] Initial support for Marvell Orion5x SoC
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud > Sent: Sunday, November 15, 2009 1:27 PM > To: U-Boot@lists.denx.de > Subject: [U-Boot] [PATCH V2 1/3 CORRECTED] Initial support > for Marvell Orion5x SoC > > ** ATTENTION: this patch supersedes the previous '1/3' patch in > the same series. The correction is the removal of Kirkwood-inherited > device init code unused at the moment and partly inapplicable to > Orion5x anyway. This correct patch has been run through checkpatch.pl > again with the exact same result as its predecessor (6 false pos). > > Sorry for the inconvenience. Please post this patch as v3 with above description as change log for v3 Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Kirkwood: Makefile cleanup- fixed ordering (cosmetic change)
As per coding guidlines, it is good to maintain proper ordering in the makefiles. This was missed during initial coding, corrected here. This was discovered during orion5x code review Thanks to Albert Aribaud for this. Signed-off-by: Prafulla Wadaskar --- cpu/arm926ejs/kirkwood/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cpu/arm926ejs/kirkwood/Makefile b/cpu/arm926ejs/kirkwood/Makefile index d73e210..fc2cc03 100644 --- a/cpu/arm926ejs/kirkwood/Makefile +++ b/cpu/arm926ejs/kirkwood/Makefile @@ -26,8 +26,8 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(SOC).a -COBJS-y= dram.o -COBJS-y+= cpu.o +COBJS-y= cpu.o +COBJS-y+= dram.o COBJS-y+= mpp.o COBJS-y+= timer.o -- 1.5.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
